
Zitat von
raytracer
das problem wurde wohl mit dem tool behoben,
Na, wenigstens das.
trotzdem ist der hänger noch da.
o.k.
die fehlermelödung taucht iom ereignisprotokoll auch nicht mehr auf.
Gut.
ich finde keinen prozess der das system aufhält,
Wenn du es ganz genau wissen willst, könntest du wohl diese beiden Tools (in der Reihenfolge) benutzen:
Windows® Performance Recorder (WPR)
Windows® Performance Analyzer (WPA)
Siehe hier. Mit etwas Googeln (Windows Performance Recorder Analyzer boot) solltest du diverse Blogs mit Anleitungen dazu finden.
Aber aufgepasst: Die Tools gibt es wohl über verschiedene herunterzuladende Pakete (Windows Assessment and Deployment Kit wie auch Windows SDK). Und die gibt es auch noch in verschiedenen Versionen, ersteres je nach Betriebssystemversion und letzteres je nach Entwicklungskitversion. Nicht dass du dir etwas allzu Veraltetes unterjubeln lässt!
Ob diese Tools aus der aktuellen Windows-10-Version des Windows Assessment and Deployment Kit abwärtskompatibel zu Windows 8.1 sind, weiß ich nicht. Falls sie inkompatibel sind bzw. nicht richtig funktionieren, brauchst du wohl die Version zu Windows 8.1. Über die Installer der SDKs würde ich die eher nicht beziehen, und was seitens Microsoft zu Windows 7 angeboten wird, würde ich nicht mehr nehmen, weil Windows 7 bei der Timer-Technologie und demzufolge auch bei den Schnittstellen noch simpler bzw. anders als Windows 8.1 gestrickt ist. Nicht dass das wegen veralteter Tools in die Hose geht.
Andersherum, also mit Tools zu Windows 10, müsste es eigentlich klappen, aber sicher bin ich mir trotzdem nicht. Wenn du ein Tool installierst, dann muss die alte Version vorher vollständig deinstalliert worden sein, vorsichtshalber immer mit anschließendem Neustart, bevor du eine andere Version installierst. Nicht dass du dir das nächste Problem einfängst (bei Microsoft gibt es immer wieder Probleme, die bei ein wenig mehr Sorgfalt in Entwicklung und Paketierung nicht sein müssten, weshalb vorausschauendes Handeln umso angebrachter ist).
Nach meinem Geschmack ist es aber nicht, gleich so mit Kanonen auf Spatzen zu schießen. Beispielsweise könntest du erst mal über die Autostart-Optionen des Task-Managers von Windows durch Deaktivieren einzelner optionaler Startprozesse eine Eingrenzung versuchen. Dienste von Windows würde ich erst mal außen vor lassen, weil es viel öfter an Komfortfunktionen, Updatern oder Treiberkonfigurationsprogrammen usw. als an Windows selbst liegt. Manchmal wird bei jedem Start eine Software erneut installiert, um ihre Verfügbarkeit durchzusetzen. Bei mir sind das Komponenten aus dem Treiberinstallationspaket von AMD. Das dauert dann typischerweise ein bis zwei Sekunden (manchmal auch länger), was ganz normal ist.
Autoruns bietet ja auch die Möglichkeit, einzelne Startoptionen zu deaktivieren, womit man allerdings vorsichtig sein muss. Ich würde da erst mal alles unangetastet lassen, was zu Windows gehört oder von Microsoft stammt. Mit Fremdanbieterkomponenten könnte man durchaus experimentieren (nur testweise deaktivieren, nicht löschen).
Eine Startprotokollierung soll auch unter den Optionen von Process Monitor verfügbar sein. Ob dir das etwas bringt, weiß ich allerdings nicht, käme also auf einen Versuch an.
dafür aber fehlt laut autoruns tool der syswow64 ordner der gestartet wird bzw. die datein dadrinn die gestartet werden sollen fehlen. kann das der grund sein?
Dass etwas fehlt, liegt oftmals nicht daran, dass es wirklich fehlen würde, sondern daran, dass der Startpfad (im weitesten Sinne) nicht weiter aufgelöst werden konnte, z.B. bei Angabe von Parametern, beispielseise an rundll32.exe. Also muss man dem schon jeweils im Detail nachgehen, z.B. indem man den entsprechenden Pfad in der Registry nachguckt und auf seine Funktion hin überprüft. Das ist dann leider Handarbeit. Kann sein, dass etwas fehlt, aber oftmals ist es nicht so. Und manche Einträge sind Altlasten aus alten Windowsversionen, die da bestenfalls noch aus Kompatibilitätsgründen drin sind, wobei dann wirklich kein Ziel vorhanden ist.
Wenn du eine Frage zu einem konkreten Eintrag, Pfad oder Ordner hast, wo du dir nicht sicher bist, könntest du das hier anbringen und vielleicht Glück haben, dass man sie dir beantworten kann. Allerdings bräuchte man dazu möglichst vollständige Informationen, also z.B. die Zeile, wie sie in AutoRuns angezeigt wird und auch die Quelle, aus der die Information stammt, also z.B. was AutoRuns aus der Registry gelesen hat. Nur mit "SysWOW64" (als Beispiel) lässt sich leider nichts anfangen, mit etwas Kontext eventuell durchaus. Allerdings ließe sich hier schon vermuten, dass AutoRuns vielleicht (speziell in diesem Kontext) die Umleitung nicht passend aufgelöst bekommt.
kann ich die autostartprogramme nicht schneller starten lassen?
Schneller nicht, sonst würde Microsoft das im Auslieferungszustand machen.
Edit (der aktuelle Stand):
Also passt hier Autostartprogramme im wörtlichen Sinn, wobei ich das (hypothetisch) weitläufiger aufgefasst hatte (z.B. die Aufgabenplanung oder ganz normale Dienste betrifft das nicht, weshalb für diese der obige Satz immer noch stimmt. Aber gerade bei Autostartprogrammen im engeren Sinne wurde das Verhalten geändert, weshalb der Satz tatsächlich unzutreffend ist.). Also die neue Antwort:
Doch, man kann (wie du inzwischen herausgefunden hast), seitdem Microsoft bei irgendeiner Version von Windows eine Verzögerung von 10 Sekunden eingeführt hat. Das hatte ich nicht auf dem Schirm, da ich noch ganz bei den alten Systemen gewesen bin, die das noch nicht hatten. Ansonsten hat mich das selten gestört, weil ich immer alles rausschmeiße, was man nicht automatisch mitgestartet haben will, wobei das fast alles ist. Beim Rest fällt die Verzögerung normalerweise nicht auf, weil die meisten Systeme gar nicht so schnell sind, sodass die 10 Sekunden derzeit noch in den meisten Fällen gut gewählt sind, weil die zuvor gestarteten Prozesse noch gar nicht mit der Ausführung ihrer Aufgaben fertig sind. In anderen Fällen wird z.B. die Aufgabenplanung verwendet, welche von diesem Verzögerungswert nicht betroffen ist. Diese Zeitspanne stört also erst dann, wenn bereits alles andere sehr schnell ist, wie es insbesondere unter Verwendung einer SSD oder einer Hybrid-Festplatte vorkommt.
Das alles, insbesondere in Verbindung mit der Problembeschreibung, hat dazu geführt, dass ich eher davon ausging, dass es um ein richtiges Problem und nicht lediglich um erwünschten Komfort gehen sollte.
Das passt nicht mehr in den aktuellen Kontext (bleibt ansonsten unberührt):
Eventuell kannst du Wartezeiten auf nicht reagierende Dienste verkürzen, aber das kann irgendwann, wenn du gar nicht mehr damit rechnest, zu Fehlern führen, weil eben doch solange gewartet werden muss, weshalb ich davon die Finger lassen würde. Am Symptom anstatt an der Ursache anzusetzen, ist eine ganz schlechte Idee, auch wenn sie noch so verlockend erscheinen mag.
man kann ja auch ne verzögerung einstellen, kann man dann auch die priorität ändern oder so?
Die Services sind zu Gruppen zusammengefasst, und die sind in der Tat priorisiert. Da würde ich auf jeden Fall die Finger von lassen, es sei denn, du weißt genau, was du tust. Normalerweise hat alles seinen guten Grund. Und falls du nicht diese Priorisierung (wo es im weitesten Sinne um Abhängigkeiten geht), sondern die Prozesspriorität meinst: Wenn du die heraufgesetzt bekommst, dann verzögern sich dadurch im Zweifel andere Prozesse, weshalb da wenig zu gewinnen ist. Und gar nichts gewinnst du, wenn der Prozess, der so lange braucht, in einer blockierenden Funktion wartet, bis das Betriebssystem den Kontrollfluss an diese zurückgibt. Natürlich könnte man dann analysieren wollen, worauf denn gewartet wird, umd ann dort erneut anzusetzen. Aber dann wird es allmählich verdammt komplex. Meistens lohnt sich so ein Herumstochern in der Tiefe nicht, weil Probieren (Ausschlussprinzip) schneller geht oder weil das Problem doch nicht so drängend ist, dass der Aufwand gerechtfertigt wäre. Aber man kann schon einiges machen, wenn man dazu die nötige Zeit und Geduld hat.