Windows BSOD / driver debugging

Windows BSOD / driver debugging
« kdy: 11. 01. 2021, 22:19:36 »
Caute,

ako sa debuguje BSOD / driver na Windows bez debug symbolov? Dostavam BSOD pri reboote a shutdowne a nedostal som sa daleko. Mam cely dump pamate.

Kód: [Vybrat]
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
subsystem.
Arg2: 000000000000012c, Timeout in seconds.
Arg3: ffffc4872f714040, The thread currently holding on to the Pnp lock.
Arg4: fffff8070c48f880, nt!TRIAGE_9F_PNP on Win7 and higher
...
IMAGE_NAME:  vwifibus.sys
MODULE_NAME: vwifibus
FAULTING_MODULE: fffff807136f0000 vwifibus

Ocividne to robi vwifibus, ale mam iba verejne symboly a IRP nic podozrive neobsahuje:
Kód: [Vybrat]
0: kd> !dt nt!TRIAGE_9F_PNP fffff8070c48f880
No export dt found
0: kd> !irpfind

Scanning large pool allocation table for tag 0x3f707249 (Irp?) (ffffc48728ab0000 : ffffc48728c30000)

  Irp            [ Thread ]         irpStack: (Mj,Mn)   DevObj          [Driver]         MDL Process
ffffc487211f2d70 [0000000000000000] Irp is complete (CurrentLocation 4 > StackCount 3)
ffffc4872782db10 [0000000000000000] Irp is complete (CurrentLocation 14 > StackCount 13)
ffffc487278419a0 [0000000000000000] Irp is complete (CurrentLocation 12 > StackCount 11)
ffffc4872780a0d0 [0000000000000000] Irp is complete (CurrentLocation 18 > StackCount 17)
ffffc48721727a40 [0000000000000000] irpStack: ( f, 0)  00000000 [00000000: Could not read device object or _DEVICE_OBJECT not found
]
ffffc48727827b10 [ffffc4872b934080] irpStack: ( d, 0)  ffffc4872146a810 [ \FileSystem\Npfs]
ffffc487278190d0 [0000000000000000] irpStack: ( f, 0)  ffffc48721b27b00 [ \Driver\USBXHCI]
ffffc4872d1ceac0 [ffffc4872d6460c0] irpStack: ( d, 0)  ffffc4872146a810 [ \FileSystem\Npfs]
ffffc487278040d0 [0000000000000000] irpStack: ( 3, 0)  ffffc48727820060 [ \Driver\HidUsb] 0x0000000000000000
ffffc487277e7830 [ffffc4872d106040] irpStack: ( d, 0)  ffffc4872146a810 [ \FileSystem\Npfs]
ffffc48721838a00 [0000000000000000] Irp is complete (CurrentLocation 4 > StackCount 3) 0x0000000000000000
ffffc487277e90d0 [0000000000000000] irpStack: ( f, 0)  ffffc48721b27b00 [ \Driver\USBXHCI]
ffffc487277e9830 [ffffc4872d107080] irpStack: ( e,20)  ffffc4872172f8f0 [ \Driver\AFD] 0xffffc4872d07f0c0
ffffc487277b2a40 [0000000000000000] irpStack: ( 0, 0)  00000000 [00000000: Could not read device object or _DEVICE_OBJECT not found
]
ffffc487277e10d0 [0000000000000000] Irp is complete (CurrentLocation 18 > StackCount 17)
ffffc48727806830 [ffffc4872e74b080] irpStack: ( c, 2)  ffffc48721771030 [ \FileSystem\Ntfs]
ffffc48727722700 [ffffc4872d17d040] irpStack: ( e,20)  ffffc4872172f8f0 [ \Driver\AFD] 0xffffc4872d1d6240
ffffc4871fee6db0 [0000000000000000] irpStack: ( e, 0)  ffffc48721513ab0 [ \Driver\ACPI]
ffffc487278150d0 [0000000000000000] Irp is complete (CurrentLocation 18 > StackCount 17)
ffffc48721506ca0 [0000000000000000] Irp is complete (CurrentLocation 4 > StackCount 3) 0x0000000000000000
ffffc4872770d230 [ffffc4872df14040] irpStack: ( d, 0)  ffffc4872146a810 [ \FileSystem\Npfs]
ffffc487277b0340 [0000000000000000] Irp is complete (CurrentLocation 5 > StackCount 4) 0x0000000000000000
ffffc487215b3a10 [0000000000000000] irpStack: ( 0, 0)  00000000 [00000000: Could not read device object or _DEVICE_OBJECT not found
]
ffffc48727710700 [ffffc4872b945040] irpStack: ( e,20)  ffffc4872172f8f0 [ \Driver\AFD] 0xffffc4872b98a0c0

Searching nonpaged pool (ffffc48000000000 : ffffd48000000000) for tag 0x3f707249 (Irp?)

Co nepomohlo:
  • odinstalovanie wifi - teda zakaz a nasledne odobratie, lebo odobratie priamo nikdy neskonci
  • zakaz wifi v device manageri
  • postupna instalacia 3 roznych driverov pre wifi
  • zakaz power managementu PCIe
  • zakaz power managementu wifi
  • zakaz fast boot
  • citanie syslogu

Trochu pomohol safe mode, po nom to nepada. Inak je to cele reprodukovatelne a vzdy to padne v vwifibus.sys.
Nejaky tip, ako sa to debuguje? Prip. ako zistit, co tomu je? Na Googli som nic nenasiel.


Re:Windows BSOD / driver debugging
« Odpověď #1 kdy: 11. 01. 2021, 23:02:38 »
Co
Kód: [Vybrat]
!poaction?

S touto chybou jsem se důvěrně setkal ze strany vývojáře. Zřejmě je v daném ovladači (či nějakém v jeho device stacku) špatně napsaná obsluha power požadavků. Naneštěstí, napsat tu obsluhu správně je hodně netriviální (dokumentace není úplně přesná, resp. její slepé následování neřeší vše). Problém je, že pokud v obsluze uděláte jen malou chybu, testováním na ni nemáte téměř šanci přijít, protože se díky plánování může projevovat jen velmi velmi zřídka (nám se dělo myslím na jednom z cca tisíce strojů).


Re:Windows BSOD / driver debugging
« Odpověď #2 kdy: 12. 01. 2021, 15:24:49 »
Vdaka! Je mozne aspon zistit, ktory driver za to presne moze alebo to obist? Lebo vwifibus znie konkretne, ale kedze zakaz zariadenia nepomaha a original drivery z MS Update to robia tiez, tak je za tym mozno nieco dalsie.

S touto chybou jsem se důvěrně setkal ze strany vývojáře. Zřejmě je v daném ovladači (či nějakém v jeho device stacku) špatně napsaná obsluha power požadavků. Naneštěstí, napsat tu obsluhu správně je hodně netriviální (dokumentace není úplně přesná, resp. její slepé následování neřeší vše). Problém je, že pokud v obsluze uděláte jen malou chybu, testováním na ni nemáte téměř šanci přijít, protože se díky plánování může projevovat jen velmi velmi zřídka (nám se dělo myslím na jednom z cca tisíce strojů).
Hmm, takze deterministicky na jednom z 1000? U mna sa to deje pri kazdom restarte, takze mam mozno smolu.

Co
Kód: [Vybrat]
!poaction?
Z toho nie som chytrejsi:
Kód: [Vybrat]
0: kd> !poaction
PopAction: fffff80706823360
  State..........: 0 - Idle
  Updates........: 0
  Action.........: None
  Lightest State.: Unspecified
  Flags..........: 10000003 QueryApps|UIAllowed
  Irp minor......: ??
  System State...: Unspecified
  Hiber Context..: 0000000000000000

Allocated power irps (PopIrpList - fffff80706823ae0)
  IRP: ffffc4872f1ce8b0 (wait-wake/S4), PDO: ffffc48727820060
  IRP: ffffc4872de078a0 (wait-wake/S4), PDO: ffffc487277a2060
  IRP: ffffc4872f4488a0 (wait-wake/S4), PDO: ffffc4872781a060
  IRP: ffffc487300cf010 (wait-wake/S0), PDO: ffffc48721a8cdb0
  IRP: ffffc4872f31b8e0 (wait-wake/S0), PDO: ffffc48721553360

Irp worker threads (PopIrpThreadList - fffff80706820b50)
  THREAD: ffffc4871fc7b040 (static)
  THREAD: ffffc4871fc90040 (static)
  THREAD: ffffc4872d2cf080 (dynamic)
  THREAD: ffffc48730186080 (dynamic)
  THREAD: ffffc4872d2ce080 (dynamic)
  THREAD: ffffc4872d371080 (dynamic)
  THREAD: ffffc4872d35d080 (dynamic)
  THREAD: ffffc4872d3be080 (dynamic)
  THREAD: ffffc4872e890080 (dynamic)
  THREAD: ffffc4872f72b080 (dynamic)
  THREAD: ffffc4872ecf1080 (dynamic)
  THREAD: ffffc4872d62f080 (dynamic)
  THREAD: ffffc4872e391080 (dynamic)
  THREAD: ffffc4872e398080 (dynamic)
  THREAD: ffffc48727e96080 (dynamic)

Broadcast in progress: FALSE
Is Directed DRIPS Transition: FALSE

Device State ffffc4872e6f5a00
  Irp minor......: ??
  System State...: Unspecified
  Worker thread..: ffffc4872b97f080
  Status.........: 0
  Waking.........: FALSE
  Cancelled......: FALSE
  Ignore errors..: FALSE
  Ignore not imp.: FALSE

Order:

Re:Windows BSOD / driver debugging
« Odpověď #3 kdy: 13. 01. 2021, 21:13:15 »
Největší studnice informací při debuggingu BSODs je pro mě Patrick ze sysnative (již neaktivní, protože army). Skvěle vysvětluje tak, že to i běžný Windows power user pochopí.
https://www.sysnative.com/forums/threads/pnp-timeouts-0x9f.9153/

Doporučuju, třeba na něco přijdeš.

Na českých fórech už moc zkušených aktivních lidí, kteří umí rozklíčovat BSOD, neznám.

Re:Windows BSOD / driver debugging
« Odpověď #4 kdy: 13. 01. 2021, 22:27:09 »
Citace
Hmm, takze deterministicky na jednom z 1000? U mna sa to deje pri kazdom restarte, takze mam mozno smolu.
Ano, v podstatě tak. Dělo se to stabilně na jednom stroji z mnoha (vždy tom stejném).

Ten výstup z !poaction vypadá, že by systém zrovna nepřecházel do nového stavu. Ale logickým krokem je pak se podívat (příkaz !thread) na vlákna v IRP worker threads. Nejzajímavější jsou jejich zásobníky volání (pokud máte správně nastaveny ladící symboly, což by ve výchozím stavu měly +- být), protože podle názvů ovladačů a funkcí, v nichž se právě nachází, lze někdy odhanout, co se děje.

Užitečné také může být se přes !thread podívat na vlákno ffffc4872f714040, které drží jeden z důležitých zámků a možná se zaseklo (!thread ffffc4872f714040).


Re:Windows BSOD / driver debugging
« Odpověď #5 kdy: 16. 01. 2021, 00:06:49 »
https://www.sysnative.com/forums/threads/pnp-timeouts-0x9f.9153/m.
Dakujem! Toto viedlo na podozrenie na deadlock, kedze mam dva thready s lockmi, kde obidva cakaju KeWaitForSingleObject - neviem parametre volani, takze je to iba tip.

Kód: [Vybrat]
0: kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks..

Resource @ nt!IopDeviceTreeLock (0xfffff80706844a20)    Shared 1 owning threads
     Threads: ffffc4872f714040-01<*>
KD: Scanning for held locks.

Resource @ nt!PiEngineLock (0xfffff80706844b80)    Exclusively owned
    Contention Count = 32
    NumberOfExclusiveWaiters = 2
     Threads: ffffc4872f714040-01<*>

     Threads Waiting On Exclusive Access:
              ffffc4872fdf6040       ffffc4872b97f080       
KD: Scanning for held locks...........................................................................................

Resource @ 0xffffc48722bef290    Exclusively owned
    Contention Count = 8
     Threads: ffffc48721c1a040-01<*>
KD: Scanning for held locks...
15706 total locks, 3 locks currently held

Citace
Hmm, takze deterministicky na jednom z 1000? U mna sa to deje pri kazdom restarte, takze mam mozno smolu.
Ano, v podstatě tak. Dělo se to stabilně na jednom stroji z mnoha (vždy tom stejném).
Aha, tak ked to tak mam, tak je to bez velkych sanci.

Ale logickým krokem je pak se podívat (příkaz !thread) na vlákna v IRP worker threads. Nejzajímavější jsou jejich zásobníky volání (pokud máte správně nastaveny ladící symboly, což by ve výchozím stavu měly +- být), protože podle názvů ovladačů a funkcí, v nichž se právě nachází, lze někdy odhanout, co se děje.

Užitečné také může být se přes !thread podívat na vlákno ffffc4872f714040, které drží jeden z důležitých zámků a možná se zaseklo (!thread ffffc4872f714040).
Kód: [Vybrat]
0: kd> !thread ffffc4872f714040
THREAD ffffc4872f714040  Cid 0004.0a4c  Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) KernelMode Non-Alertable
    ffffbf84ce0f4580  NotificationEvent
IRP List:
    ffffc4872eefaa20: (0006,04c0) Flags: 00000000  Mdl: 00000000
Not impersonating
DeviceMap                 ffffd7864de47480
Owning Process            ffffc4871fcce080       Image:         System
Attached Process          N/A            Image:         N/A
Wait Start TickCount      10945          Ticks: 19200 (0:00:05:00.000)
Context Switch Count      3883           IdealProcessor: 1  NoStackSwap
UserTime                  00:00:00.000
KernelTime                00:00:00.390
Win32 Start Address nt!ExpWorkerThread (0xfffff80705e25870)
Stack Init ffffbf84ce0f4c90 Current ffffbf84ce0f4140
Base ffffbf84ce0f5000 Limit ffffbf84ce0ef000 Call 0000000000000000
Priority 15 BasePriority 12 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffbf84`ce0f4180 fffff807`05e65850 : ffff9b00`73d55180 00000000`ffffffff 00000000`00000000 ffffc487`2d3c0158 : nt!KiSwapContext+0x76
ffffbf84`ce0f42c0 fffff807`05e64d7f : 20061fff`00000002 00000000`00000001 ffffbf84`ce0f4480 fffff807`00000000 : nt!KiSwapThread+0x500
ffffbf84`ce0f4370 fffff807`05e64623 : ffffbf84`00000000 fffff807`00000000 00000000`00000000 ffffc487`2f714180 : nt!KiCommitThreadWait+0x14f
ffffbf84`ce0f4410 fffff807`0b7688a1 : ffffbf84`ce0f4580 ffffc487`00000000 fffff807`00000000 00470080`05000000 : nt!KeWaitForSingleObject+0x233
ffffbf84`ce0f4500 fffff807`0b78e1da : ffffc487`2dfa21a0 ffffc487`2dfa2050 00000000`00000000 00000000`00000000 : ndis!ndisWaitForKernelObject+0x21
ffffbf84`ce0f4540 fffff807`0b6bbc66 : ffffc487`2eefaa20 ffffbf84`ce0f45f0 00000000`00000000 ffffc487`2dfa21a0 : ndis!ndisPnPIrpRemoveDevice+0x126
ffffbf84`ce0f45b0 fffff807`05e52f55 : 00000000`00000001 ffffc487`2dfa2050 00000000`00000001 ffffbf84`ce0f4710 : ndis!ndisPnPDispatch+0x30926
ffffbf84`ce0f4620 fffff807`06287650 : 00000000`00000000 ffffc487`2dfa2050 ffffbf84`ce0f4710 fffff807`06333d80 : nt!IofCallDriver+0x55
ffffbf84`ce0f4660 fffff807`06333a89 : ffffc487`2ddbfa70 ffffc487`2ddbfa70 ffffc487`2df20c70 00000000`00000002 : nt!IopSynchronousCall+0xf8
ffffbf84`ce0f46d0 fffff807`05f6c5c4 : ffffd786`5e0244d0 ffffc487`2df20c70 00000000`00000001 00000000`0000000a : nt!IopRemoveDevice+0x105
ffffbf84`ce0f4780 fffff807`06333652 : ffffc487`2df20c70 00000000`00000018 00000000`00000000 fffff807`06844a80 : nt!PnpRemoveLockedDeviceNode+0x1ac
ffffbf84`ce0f47e0 fffff807`06333387 : ffffc487`2df20c70 ffffbf84`ce0f4860 00000000`00000018 00000000`00000000 : nt!PnpDeleteLockedDeviceNode+0x4e
ffffbf84`ce0f4820 fffff807`063369f1 : ffffc487`2ddbfa70 00000000`00000002 ffffc487`2e302510 00000000`00000000 : nt!PnpDeleteLockedDeviceNodes+0xf7
ffffbf84`ce0f48a0 fffff807`06336c84 : 00000000`00000000 ffffbf84`ce0f4920 ffffc487`2ddbfa70 00000000`00000000 : nt!PipRemoveDevicesInRelationList+0x8d
ffffbf84`ce0f48f0 fffff807`06336b29 : ffffc487`2e302510 00000000`00000001 ffffc487`2e302510 00000000`00000000 : nt!PnpDelayedRemoveWorker+0x114
ffffbf84`ce0f4930 fffff807`05f6d788 : 00000000`00000000 00000000`00000001 00000000`00000000 ffffc487`2df20c70 : nt!PnpChainDereferenceComplete+0xfd
ffffbf84`ce0f4960 fffff807`06332276 : 00000000`00000001 ffffbf84`ce0f4a59 ffffd786`53611da0 00000000`00000001 : nt!PnpIsChainDereferenced+0xac
ffffbf84`ce0f49e0 fffff807`06330347 : ffffbf84`ce0f4b20 ffffc487`2df20c00 ffffbf84`ce0f4b00 ffffd786`00000001 : nt!PnpProcessQueryRemoveAndEject+0x28a
ffffbf84`ce0f4ac0 fffff807`06309e9e : ffffd786`5e0244d0 ffffd786`5c0a8180 ffffc487`1fcaec00 00000000`00000000 : nt!PnpProcessTargetDeviceEvent+0xeb
ffffbf84`ce0f4af0 fffff807`05e25975 : ffffc487`2f714040 ffffc487`2f714040 ffffc487`1fcaece0 ffffc487`2f303c00 : nt!PnpDeviceEventWorker+0x2ce
ffffbf84`ce0f4b70 fffff807`05f17e25 : ffffc487`2f714040 00000000`00000080 ffffc487`1fcce080 000f8225`bcbbbdff : nt!ExpWorkerThread+0x105
ffffbf84`ce0f4c10 fffff807`05ffcdd8 : fffff807`03ba9180 ffffc487`2f714040 fffff807`05f17dd0 000001d7`9fa65cf0 : nt!PspSystemThreadStartup+0x55
ffffbf84`ce0f4c60 00000000`00000000 : ffffbf84`ce0f5000 ffffbf84`ce0ef000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28
Tu parametre urcite nesedia, takze neviem, na co sa caka. Tipujem x86-64 call convention, kde sa az parametre od 5 predavaju na stacku a tie tu vidim. (!dv neukazuje nic)
Tu sa iba maze device cez IRP, tak som isiel pozriet na IRP:
Kód: [Vybrat]
0: kd> !irp ffffc4872eefaa20
Irp is active with 3 stacks 3 is current (= 0xffffc4872eefab80)
 No Mdl: No System Buffer: Thread ffffc4872f714040:  Irp stack trace. 
     cmd  flg cl Device   File     Completion-Context
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000   

Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000   

Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_PNP(1b), IRP_MN_REMOVE_DEVICE - (2)]
            0  0 ffffc4872dfa2050 00000000 00000000-00000000   
       \Driver\vwifimp
Args: 00000000 00000000 00000000 00000000
0: kd> !devstack ffffc4872dfa2050
  !DevObj           !DrvObj            !DevExt           ObjectName
> ffffc4872dfa2050  \Driver\vwifimp    ffffc4872dfa21a0  NDMP3
  ffffc4872ddbfa70  \Driver\vwifibus   ffffc4872de32f80  0000006e
!DevNode ffffc4872df20c70 :
  DeviceInst is "{5d624f94-8850-40c3-a3fa-a4fd2080baf3}\vwifimp_wfd\5&373d53f1&6&20"
  ServiceName is "vwifimp"
0: kd> !devobj ffffc4872dfa2050
Device object (ffffc4872dfa2050) is for:
 NDMP3 \Driver\vwifimp DriverObject ffffc4872de04300
Current Irp 00000000 RefCount 0 Type 00000017 Flags 00002050
SecurityDescriptor ffffd7864e2997e0 DevExt ffffc4872dfa21a0 DevObjExt ffffc4872dfa3900
ExtensionFlags (0x00000808)  DOE_REMOVE_PROCESSED, DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
AttachedTo (Lower) ffffc4872ddbfa70 \Driver\vwifibus
Device queue is not busy.
0: kd> !devobj ffffc4872ddbfa70
Device object (ffffc4872ddbfa70) is for:
 0000006e \Driver\vwifibus DriverObject ffffc48721a78e40
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00003044
SecurityDescriptor ffffd7864e2997e0 DevExt ffffc4872de32f80 DevObjExt ffffc4872ddbfbe8 DevNode ffffc4872df20c70
ExtensionFlags (0x00000808)  DOE_REMOVE_PROCESSED, DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000180)  FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffc4872dfa2050 \Driver\vwifimp
Device queue is not busy.
0: kd> !devnode ffffc4872df20c70
DevNode 0xffffc4872df20c70 for PDO 0xffffc4872ddbfa70
  Parent 0000000000   Sibling 0000000000   Child 0000000000   
  InstancePath is "{5d624f94-8850-40c3-a3fa-a4fd2080baf3}\vwifimp_wfd\5&373d53f1&6&20"
  ServiceName is "vwifimp"
  State = DeviceNodeDeletePendingCloses (0x313)
  Previous State = DeviceNodeStarted (0x308)
  StateHistory[18] = DeviceNodeStarted (0x308)
  StateHistory[17] = DeviceNodeAwaitingQueuedDeletion (0x30e)
  StateHistory[16] = DeviceNodeStarted (0x308)
  StateHistory[15] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[14] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[13] = DeviceNodeStarted (0x308)
  StateHistory[12] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[11] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[10] = DeviceNodeStarted (0x308)
  StateHistory[09] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[08] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[07] = DeviceNodeStarted (0x308)
  StateHistory[06] = DeviceNodeStartPostWork (0x307)
  StateHistory[05] = DeviceNodeStartCompletion (0x306)
  StateHistory[04] = DeviceNodeStartPending (0x305)
  StateHistory[03] = DeviceNodeResourcesAssigned (0x304)
  StateHistory[02] = DeviceNodeDriversAdded (0x303)
  StateHistory[01] = DeviceNodeInitialized (0x302)
  StateHistory[00] = DeviceNodeUninitialized (0x301)
  StateHistory[19] = Unknown State (0x0)
  Flags (0x6c010128)  DNF_REENUMERATE, DNF_IDS_QUERIED,
                      DNF_NO_RESOURCE_REQUIRED, DNF_DEVICE_GONE,
                      DNF_NO_LOWER_DEVICE_FILTERS, DNF_NO_LOWER_CLASS_FILTERS,
                      DNF_NO_UPPER_DEVICE_FILTERS, DNF_NO_UPPER_CLASS_FILTERS
  UserFlags (0x00000002)  DNUF_DONT_SHOW_IN_UI
  CapabilityFlags (0x00000a81)  DeviceD1, SilentInstall,
                                SurpriseRemovalOK, WakeFromD1
Takze device skoncil v "Unknown state", aj ked neviem, preco sa po deletion znova snazil startovat. Je divne, ze devicy nie su busy a aj tak to skoncio takto.

Kazdopadne vdaka za pomoc!

Re:Windows BSOD / driver debugging
« Odpověď #6 kdy: 16. 01. 2021, 11:34:50 »
Citace
Dakujem! Toto viedlo na podozrenie na deadlock, kedze mam dva thready s lockmi, kde obidva cakaju KeWaitForSingleObject - neviem parametre volani, takze je to iba tip.
Příkaz !locks pracuje pouze s objekty typu Executive Resource (ERESOURCE), což jsou poměrně těžkotonážní RW zámky, které krom toho, že si pamatují, kdo je aktuálně vlastní (je zamkl), tak jsou uloženy v rámci jednoho spojového seznamu (obousměrny s hlavou), takže je možné je všechny projít a vypsat jejich stav (což !locks dělá). A můžete si případně nakreslit graf, ve kterém uvidíte deadlock jako kružnici.

Naneštěstí tyhle objekty nejsou zdaleka jediným typem synchronizačních primitiv. Často se používají notifikační/synchronizační eventy, semafory, mutexy a další, u kterých se nedozvíte, kdo je drží (taková informace v jejich případě nedává smysl). V některých případech u vlákna alespoň vidíte, na jaký objekt čeká (kolem řádku IRP:), ale ne vždy. Což v zásadě znamená, že může dojít k deadlocku, který z výpisu paměti v podstatě nedokážete jednoznačně detekovat.

Citace
u parametre urcite nesedia, takze neviem, na co sa caka. Tipujem x86-64 call convention, kde sa az parametre od 5 predavaju na stacku a tie tu vidim. (!dv neukazuje nic)
Ano, je tam Windowsí fastcall, jak píšete. KeWaitForSingleObject má 5 parametrů, ale nemyslím, že by jejich znalost vám k něčemu byla (viz výše). Bohužel, v NDIS internals se neorientuji.

Citace
Takze device skoncil v "Unknown state", aj ked neviem, preco sa po deletion znova snazil startovat. Je divne, ze devicy nie su busy a aj tak to skoncio takto.
Položka state v !devnode ukazuje "delete pending close", což znamená, že zařízení se maže. Zbytek udává posledních 20 stavů, ve kterých se zařízení nacházelo.

Upřímně, také jsem ještě neviděl zařízení, které by bylo "busy". Celkem dost mechanismů implementovaných jádrem ohledně zařízení se dnes již moc nepoužívá.

Například, pomocí API jádra je možné požadavky (IRP), které zařízení nemůže inhed obsloužit, ukládat do fronty v rámci jeho objektu. Obvykle si ale autoři ovladačů takovou frontu implementují sami, protože od ní požadují chování, jímž ta implementovaná jádrem nedsiponuje. A takových mechanismů je víc.