WinFuture-Forum.de: Startzeit analysieren - WinFuture-Forum.de

Zum Inhalt wechseln

Alle Informationen zum Thema Windows 7 in unserem Special. Windows 7 Download, FAQ und neue Funktionen im Überblick.
  • 4 Seiten +
  • 1
  • 2
  • 3
  • 4

Startzeit analysieren Langsame Bootzeiten seit Upgrade-Installation

#31 Mitglied ist offline   TornadoX 

  • Gruppe: aktive Mitglieder
  • Beiträge: 91
  • Beigetreten: 25. April 10
  • Reputation: 0

geschrieben 25. April 2011 - 23:47

Der wartet wieder 300 Sekunden ohne Erfolg auf den Prefetcher. Laut Services ist Superfetch gestartet.

Superfetch != Prefetcher? Wie heißt denn der Prefetcher? Vielleicht ist da der Pfad auch falsch...

EDIT: Ich habe News zu VFLT, das ist wohl nicht der Treiber vom Cisco VPN sondern vom ShrewSoft VPN was ich vorher drauf hatte (weil es keine 64 Bit Version von Cisco gab).

Die Initialisierung des Treibers hat länger als erwartet gedauert und dadurch die Leistung des Systemstartprozesses beeinträchtigt: 
	Dateiname		:	vflt
	Anzeigename		:	Shrew Lightweight Filter Driver
	Version		:	2.1.0.0005
	Gesamtzeit		:	15312ms
	Beeinträchtigungszeit	:	11080ms
	Vorfallzeit (UTC)	:	‎2011‎-‎04‎-‎25T23:10:01.656000300Z

Ich werde mal versuchen den zu löschen.

EDIT2: Ahh, das fühlt sich gut an.

Windows wurde gestartet: 
	Startdauer		:		:	104581ms
	Beeinträchtigung		:	false
	Vorfallzeit (UTC)	:	‎2011‎-‎04‎-‎25T23:21:50.656000300Z

Jetzt noch den Prefetcher vernünftig zum Laufen bringen und ich bin zufrieden. :nuke:

EDIT3: Wird der jetzt auch durch normales Starten trainiert? Ist nämlich nochmal schneller geworden nach einem erneuten Neustart.

Windows wurde gestartet: 
	Startdauer		:		:	87381ms
	Beeinträchtigung		:	false
	Vorfallzeit (UTC)	:	‎2011‎-‎04‎-‎25T23:34:34.624800200Z


EDIT4: Ok, jetzt wurde er wieder langsamer (93109ms), aber das kann man so schon mal besser aushalten als vorher.

EDIT5: Beim Start gerade eben kam:
Windows wurde gestartet: 
	Startdauer		:		:	87354ms
	Beeinträchtigung		:	false
	Vorfallzeit (UTC)	:	‎2011‎-‎04‎-‎25T23:52:00.656000300Z

Die Hintergrundoptimierungen (Vorabruf) haben länger gedauert und dadurch die Leistung des Systemstartprozesses beeinträchtigt: 
	Name		:	BackgroundPrefetchTime
	Gesamtzeit		:	52988ms
	Beeinträchtigungszeit	:	45467ms
	Vorfallzeit (UTC)	:	‎2011‎-‎04‎-‎25T23:52:00.656000300Z

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Diagnostics-Performance" Guid="{CFC18EC0-96B1-4EBA-961B-622CAEE05B0A}" /> 
  <EventID>106</EventID> 
  <Version>1</Version> 
  <Level>2</Level> 
  <Task>4002</Task> 
  <Opcode>33</Opcode> 
  <Keywords>0x8000000000010000</Keywords> 
  <TimeCreated SystemTime="2011-04-25T23:54:07.889859800Z" /> 
  <EventRecordID>9640</EventRecordID> 
  <Correlation ActivityID="{034BA908-F800-0001-0CE9-FFC4A303CC01}" /> 
  <Execution ProcessID="1576" ThreadID="2440" /> 
  <Channel>Microsoft-Windows-Diagnostics-Performance/Operational</Channel> 
  <Computer>Torben-PC</Computer> 
  <Security UserID="S-1-5-19" /> 
  </System>
- <EventData>
  <Data Name="StartTime">2011-04-25T23:52:00.656000300Z</Data> 
  <Data Name="NameLength">23</Data> 
  <Data Name="Name">BackgroundPrefetchTime</Data> 
  <Data Name="TotalTime">52988</Data> 
  <Data Name="DegradationTime">45467</Data> 
  </EventData>
  </Event>

Dieser Beitrag wurde von TornadoX bearbeitet: 26. April 2011 - 00:58

0

Anzeige



#32 _MagicAndre1981_

  • Gruppe: Gäste

geschrieben 26. April 2011 - 12:08

ist der Wert bei EnablePrefetcher auch auf 3 gestellt?
0

#33 Mitglied ist offline   TornadoX 

  • Gruppe: aktive Mitglieder
  • Beiträge: 91
  • Beigetreten: 25. April 10
  • Reputation: 0

geschrieben 26. April 2011 - 13:00

Eigentlich schon.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters]
"BootId"=dword:000005e9
"BaseTime"=dword:12f26ddb
"EnableSuperfetch"=dword:00000003
"EnablePrefetcher"=dword:00000003
"EnableBootTrace"=dword:00000000


Und C:\Windows\Prefetch hat auch viele Dateien drin (89 Elemente, alle von heute), also scheint der ja eigentlich zu laufen?

Dieser Beitrag wurde von TornadoX bearbeitet: 26. April 2011 - 13:04

0

#34 _MagicAndre1981_

  • Gruppe: Gäste

geschrieben 26. April 2011 - 14:05

eigentlich ja. stoppe den SQL Dienst und mache einen normalen Boot trace (ohne Optimierung)
0

#35 Mitglied ist offline   TornadoX 

  • Gruppe: aktive Mitglieder
  • Beiträge: 91
  • Beigetreten: 25. April 10
  • Reputation: 0

geschrieben 26. April 2011 - 18:31

Habe alle 3 SQL Server Dienste "SQL Server (SQLEXPRESS)", "SQL Server VSS Writer", "SQL Server-Browser" beendet und den Starttyp auf deaktiviert gesetzt, dann Trace gestartet: Bluescreen. Kommt jetzt bei jedem Systemstart. Ich versuche gerade Systemwiederherstellung...

EDIT: Nach Systemwiederherstellung startet das System wieder.

Dieser Beitrag wurde von TornadoX bearbeitet: 26. April 2011 - 18:45

0

#36 _MagicAndre1981_

  • Gruppe: Gäste

geschrieben 26. April 2011 - 18:48

das liegt an dem DRIVERS flag, du musst es ohne diesen Parameter starten. MS schaut sich das gerade an.
0

#37 Mitglied ist offline   TornadoX 

  • Gruppe: aktive Mitglieder
  • Beiträge: 91
  • Beigetreten: 25. April 10
  • Reputation: 0

geschrieben 26. April 2011 - 18:53

Hm aber was hat das jetzt mit dem Deaktivieren vom SQL Server zu tun? Es ging ja vorher...

Gibt es für den Fall eines Bluescreen da auch eine schnellere Möglichkeit zur Behebung? Systemwiederherstellung ist ja eigentlich vermutlich "übertrieben", weil nur xbootmgr aus dem Autostart wieder rausmüsste. Also sowas wie "abgesichterter Modus" oder so? (Ich hatte schon lange keine Bluescreens mehr. :cool:

CODE
*****************************************
*********
*****************************
* *
* Bugcheck Analysis *
* *
**************************************************
*****************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007E, {ffffffffc0000005, fffff800033c4677, fffff880031fbfd8, fffff880031fb830}

Probably caused by : hidusb.sys ( hidusb!HumCallUSB+2c1 )

Followup: MachineOwner
---------

0: kd> !analyze -v
**************************************************
*****************************
* *
* Bugcheck Analysis *
* *
**************************************************
*****************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff800033c4677, The address that the exception occurred at
Arg3: fffff880031fbfd8, Exception Record Address
Arg4: fffff880031fb830, Context Record Address

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP:
nt!IopPerfCompleteRequest+47
fffff800`033c4677 488b5008 mov rdx,qword ptr [rax+8]

EXCEPTION_RECORD: fffff880031fbfd8 -- (.exr 0xfffff880031fbfd8)
Cannot read Exception record @ fffff880031fbfd8

CONTEXT: fffff880031fb830 -- (.cxr 0xfffff880031fb830)
rax=0000000301401200 rbx=fffffa8003998700 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000100 rdi=fffffa8003998510
rip=fffff800033c4677 rsp=fffff880031fc210 rbp=fffffa8018e549d0
r8=0000000000000000 r9=fffff88006c061a0 r10=0000000000000020
r11=fffffa80190c02c0 r12=0000000000000005 r13=fffff88006c061a0
r14=0000000000000001 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010206
nt!IopPerfCompleteRequest+0x47:
fffff800`033c4677 488b5008 mov rdx,qword ptr [rax+8] ds:002b:00000003`01401208=?
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: NULL_DEREFERENCE

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000000

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800034fb0e8
0000000000000000

FOLLOWUP_IP:
hidusb!HumCallUSB+2c1
fffff880`06c043f5 3bde cmp ebx,esi

BUGCHECK_STR: 0x7E

LOCK_ADDRESS: fffff800034c6440 -- (!locks fffff800034c6440)

Resource @ nt!PiEngineLock (0xfffff800034c6440) Available

WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.


WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0xfffff800034c6440
Thread Count : 0
Thread address: 0x0000000000000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from fffff88006c043f5 to fffff800033c4677

STACK_TEXT:
fffff880`031fc210 fffff880`06c043f5 : 00000000`00000103 fffffa80`18e549d0 00000000`00000103 fffffa80`03998500 : nt!IopPerfCompleteRequest+0x47
fffff880`031fc2c0 fffff880`06c04037 : 00000000`00000012 fffff880`031fc428 fffffa80`18e89f10 00000000`000007ff : hidusb!HumCallUSB+0x2c1
fffff880`031fc360 fffff880`06c03365 : 00000000`00000000 fffff880`06c061a0 fffffa80`18e89f08 fffff880`000190b6 : hidusb!HumGetDescriptorRequest+0x143
fffff880`031fc3d0 fffff880`06c01bf8 : 00000000`00000000 fffffa80`00000012 fffffa80`18e89b30 fffffa80`18e89f08 : hidusb!HumGetDeviceDescriptor+0x79
fffff880`031fc420 fffff880`06c09565 : fffffa80`188d7a58 00000000`00000000 00000000`00000000 fffffa80`188d78b0 : hidusb!HumInitDevice+0x20
fffff880`031fc450 fffff880`047da517 : fffffa80`18e89b30 00000000`00000001 fffffa80`03998510 fffffa80`188d78b0 : hidusb!HumPnP+0x229
fffff880`031fc4c0 fffff880`047dd5e7 : fffffa80`188d7aa0 00000000`00000001 fffffa80`03998510 fffffa80`18e89ca0 : HIDCLASS!HidpCallDriverSynchronous+0x4b
fffff880`031fc520 fffff880`047daccd : 00000000`00000008 fffff880`047d7300 fffff880`047ddc60 fffffa80`188d78b0 : HIDCLASS!HidpStartDevice+0x13f
fffff880`031fc5a0 fffff880`047da64a : fffff880`047d7300 fffffa80`18e89c80 fffffa80`18e89c80 fffff880`031fc668 : HIDCLASS!HidpFdoPnp+0x20d
fffff880`031fc5d0 fffff880`047cc805 : fffff880`047d73b8 fffff880`047d64b0 fffffa80`18e89c80 fffff800`033acbf1 : HIDCLASS!HidpIrpMajorPnp+0x8a
fffff880`031fc640 fffff800`033e0fda : fffffa80`18e838f0 fffffa80`18e838f0 fffffa80`18e89b30 ffffe46a`10b092c6 : HIDCLASS!HidpMajorHandler+0xf5
fffff880`031fc6b0 fffff800`0368117e : fffffa80`188d78b0 fffffa80`18e43a00 fffffa80`18e89b30 fffffa80`18faa060 : nt!IopPerfCallDriver+0x14a
fffff880`031fc750 fffff800`033b7b2d : fffffa80`18faa060 fffffa80`18e43a00 fffff800`033c1250 00000000`00000000 : nt!PnpAsynchronousCall+0xce
fffff880`031fc790 fffff800`036904c6 : fffff800`034c6200 fffffa80`18e7fd90 fffffa80`18e43a00 fffffa80`18e7ff38 : nt!PnpStartDevice+0x11d
fffff880`031fc850 fffff800`03690764 : fffffa80`18e7fd90 fffffa80`039d0024 fffffa80`039dcd00 00000000`00000001 : nt!PnpStartDeviceNode+0x156
fffff880`031fc8e0 fffff800`036b3e96 : fffffa80`18e7fd90 fffffa80`039dcd00 00000000`00000002 00000000`00000000 : nt!PipProcessStartPhase1+0x74
fffff880`031fc910 fffff800`036b4428 : fffff800`034c3d00 00000000`00000000 00000000`00000001 00000000`00000001 : nt!PipProcessDevNodeTree+0x296
fffff880`031fcb80 fffff800`033c3b97 : 00000001`00000003 00000000`00000000 00000000`00000001 00000000`00000084 : nt!PiProcessReenumeration+0x98
fffff880`031fcbd0 fffff800`032d4a21 : fffff800`033c3870 fffff800`035c0f01 fffffa80`03a02600 fffffa80`03a02680 : nt!PnpDeviceActionWorker+0x327
fffff880`031fcc70 fffff800`03567cce : 00000000`00000000 fffffa80`03a02680 00000000`00000080 fffffa80`039f1990 : nt!ExpWorkerThread+0x111
fffff880`031fcd00 fffff800`032bbfe6 : fffff880`009e7180 fffffa80`03a02680 fffff880`009f1f40 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`031fcd40 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16


SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: hidusb!HumCallUSB+2c1

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: hidusb

IMAGE_NAME: hidusb.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7a665

STACK_COMMAND: .cxr 0xfffff880031fb830; kb

FAILURE_BUCKET_ID: X64_0x7E_hidusb!HumCallUSB+2c1

BUCKET_ID: X64_0x7E_hidusb!HumCallUSB+2c1

Followup: MachineOwner
---------

Dieser Beitrag wurde von Urne bearbeitet: 26. April 2011 - 19:31
Änderungsgrund: Urne hat das Analysedings mal geboxt.

0

#38 _MagicAndre1981_

  • Gruppe: Gäste

geschrieben 26. April 2011 - 19:16

das ist der DRIVERS flag crash, das hat damit nix zu tun. Das trat bei mir auch plötzlich mal auf.

MS schaut sich das deshalb auch gerade an.
0

#39 Mitglied ist offline   TornadoX 

  • Gruppe: aktive Mitglieder
  • Beiträge: 91
  • Beigetreten: 25. April 10
  • Reputation: 0

geschrieben 26. April 2011 - 20:34

Ok, ein neuer Trace ohne DRIVERS-Flag ist hochgeladen. VFLT-Problem müsste behoben sein, Treiber ist gelöscht. MSSQL ist auch alles deaktiviert.

Ich verstehe nur nicht, wieso die Bootzeit so stark schwankt. Ich gucke jetzt immer auf die gemessene Bootzeit und die war schon bei ca. 80 Sekunden und dann teilweise wieder ca. 120 Sekunden usw. Wieso schwankt das so? Ich dachte Superfetch sorgt dafür, dass die Zeiten von Mal zu Mal besser werden.

EDIT: Gerade in der Ereignisanzeige entdeckt:

"Das Laden folgender Boot- oder Systemstarttreiber ist fehlgeschlagen:
vflt"

Einfach den Treiber weglöschen war wohl keine gute Idee. Muss ich den auch irgendwie aus der Registry löschen? Das Program (ShrewSoft VPN) habe ich ja schon lange nicht mehr...

EDIT2: Noch ein paar Einträge zum Treiber aus der Registry gelöscht. Allerdings ließ sich "LEGACY_VFLT" nicht löschen, das ist aber ok?

Dieser Beitrag wurde von TornadoX bearbeitet: 26. April 2011 - 20:48

0

#40 _MagicAndre1981_

  • Gruppe: Gäste

geschrieben 26. April 2011 - 22:15

das Booten schwankt, weil der Prefetcher noch nicht optimal arbeitet, weil der Arbeitsstationsdienst für 30s hängt und deine Autostartprogramme (CCC, RadeonPro u.a.) dein Windowsboot für 50s verlängern, deshalb bootet er immer noch so lange (37s bis zum Desktop und 90s zum kompletten Booten)

Aber ohne den SQL server und den VPN Treiber ist das ganze schon viel besser.
0

#41 Mitglied ist offline   TornadoX 

  • Gruppe: aktive Mitglieder
  • Beiträge: 91
  • Beigetreten: 25. April 10
  • Reputation: 0

geschrieben 26. April 2011 - 23:05

Inwiefern kann man das denn noch verbessern? Kann man was gegen das hängen des Arbeitsstationsdienstes machen?

Soooo viele Autostart-Programme habe ich ja eigentlich nicht. CCC + RadeonPro brauche ich für die Grafikkarte, sonst habe ich da nur noch 1 virtuelles Laufwerk, Antivirus, Dropbox, Soundtreiber.
0

#42 _MagicAndre1981_

  • Gruppe: Gäste

geschrieben 26. April 2011 - 23:17

das CCC + RadeonPro sind aber so lahm, tausche sie gegen die ATI Tray Tools aus. Dann solltest du auch MSE austauschen, das bremst auch tierisch. In einer der letzten ct's gabs NOD32 für 1 Jahr. Bestellt das Heft für 3-4€ und nutze diese Lizenz. Ich bin mit NOD32 überglücklich.
0

#43 Mitglied ist offline   TornadoX 

  • Gruppe: aktive Mitglieder
  • Beiträge: 91
  • Beigetreten: 25. April 10
  • Reputation: 0

geschrieben 26. April 2011 - 23:40

Ich werde mal gucken ob ich das CCC einfach weglassen kann, weil RadeonPro eigentlich das gleiche kann. Das mit den ATI Tray Tools muss ich mir nochmal angucken. Da gab es irgendeinen Grund gegen. (War möglicherweise der, dass RadeonPro keine Probleme mit einem unsignierten Treiber unter einem 64 Bit System macht.)

MSE werde ich auch nochmal gucken, mag ich aber eigentlich ganz gerne, weil es nicht störend im normalen Betrieb auffällt.

Die Sache mit dem Arbeitsstationsdienst: Da kann man "nichts" machen?

Zitat

Unentbehrlich in Netzwerkumgebungen: Der Dienst erstellt und wartet Client-Verbindungen mit Remoteservern unter Verwendung des SMB-Protkolls. Ohne Arbeitsstationsdienst können keine Verbindungen zu Rechnern, Freigaben oder Druckern aufgebaut werden. Lediglich der Zugriff auf das Internet ist auch ohne den „Arbeitsstationsdienst" möglich.


Da ich noch einen Laptop habe, wäre das schade, wenn ich die im LAN nicht mehr verbinden könnte.

EDIT: CCC und Customer Care aus dem Autostart entfernt, schon besser:
Startdauer		:		:	68959ms
Beeinträchtigung		:	false
Vorfallzeit (UTC)	:	‎2011‎-‎04‎-‎26T22:51:22.656000300Z

Dieser Beitrag wurde von TornadoX bearbeitet: 26. April 2011 - 23:55

0

#44 _MagicAndre1981_

  • Gruppe: Gäste

geschrieben 27. April 2011 - 11:59

Das war zu erwarten. Das CCC ist einfach zu langsam.

probiere es mal mit NOD32 (die Trial kannst du für 30 Tage testen). Ich tippe dass der Netzwerkschutz vom MSE den Arbeitsstationsdienst blockiert.
0

#45 Mitglied ist offline   TornadoX 

  • Gruppe: aktive Mitglieder
  • Beiträge: 91
  • Beigetreten: 25. April 10
  • Reputation: 0

geschrieben 27. April 2011 - 23:45

Ich denke ich höre jetzt mit den Optimierungen auf. Mit bisschen über 1 Minute bin ich sehr zufrieden. :D Wahnsinns Verbesserung zu vorher.

Vielen Dank für deine Hilfe!
0

Thema verteilen:


  • 4 Seiten +
  • 1
  • 2
  • 3
  • 4

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0