Hi,
I am analyzing a failed driver unload issue. I have already been through other related posts and this link:
http://msdn.microsoft.com/en-us/library/ff540608(VS.85).aspx
The device is an usb based network adapter and the issue is there on Vista OS on which we have the NDIS 6.0 driver with KMDF. The driver “sometimes” fails to unload when the system is put to hibernate, then the usb device is disconnected and connected back to some other port, and then the system is resumed. This failed unload issue takes about 7-8 cycles of the procedure stated above to get reproduced.
It clearly is not something where something obvious is missing, as it doesn’t occur every time. I’ve also put prints in MiniportHalt and MiniportUnload and both these functions get called (both entry and exit checked) even when unload fails.
When the issue does get reproduced (entry in device manager appears with yellow mark with error code 38), following are my observations:
0: kd> !object 837d20d8
Object: 837d20d8 Type: (82f04d40) Device
ObjectHeader: 837d20c0 (old version)
HandleCount: 0 PointerCount: 1
0: kd> dt nt!_object_header 837d20c0
+0x000 PointerCount : 1
+0x004 HandleCount : 0
+0x004 NextToFree : (null)
+0x008 Type : 0x82f04d40 _OBJECT_TYPE
+0x00c NameInfoOffset : 0x10 ‘’
+0x00d HandleInfoOffset : 0 ‘’
+0x00e QuotaInfoOffset : 0 ‘’
+0x00f Flags : 0x2 ‘’
+0x010 ObjectCreateInfo : 0x00000001 _OBJECT_CREATE_INFORMATION
+0x010 QuotaBlockCharged : 0x00000001
+0x014 SecurityDescriptor : (null)
+0x018 Body : _QUAD
Any hints on how do I proceed further from here?
If I put breakpoint on the PointerCount (837d20c0), it gets lost as soon as system hibernates.
Regards,
Suresh
Have you checked the threads in the system to see if your old instance is
still out there waiting for something? A couple of commands to try would be:
!stacks 2 ndis!
!pnptriage
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@windbg…
Hi,
I am analyzing a failed driver unload issue. I have already been through
other related posts and this link:
http://msdn.microsoft.com/en-us/library/ff540608(VS.85).aspx
The device is an usb based network adapter and the issue is there on Vista
OS on which we have the NDIS 6.0 driver with KMDF. The driver “sometimes”
fails to unload when the system is put to hibernate, then the usb device is
disconnected and connected back to some other port, and then the system is
resumed. This failed unload issue takes about 7-8 cycles of the procedure
stated above to get reproduced.
It clearly is not something where something obvious is missing, as it
doesn’t occur every time. I’ve also put prints in MiniportHalt and
MiniportUnload and both these functions get called (both entry and exit
checked) even when unload fails.
When the issue does get reproduced (entry in device manager appears with
yellow mark with error code 38), following are my observations:
0: kd> !object 837d20d8
Object: 837d20d8 Type: (82f04d40) Device
ObjectHeader: 837d20c0 (old version)
HandleCount: 0 PointerCount: 1
0: kd> dt nt!_object_header 837d20c0
+0x000 PointerCount : 1
+0x004 HandleCount : 0
+0x004 NextToFree : (null)
+0x008 Type : 0x82f04d40 _OBJECT_TYPE
+0x00c NameInfoOffset : 0x10 ‘’
+0x00d HandleInfoOffset : 0 ‘’
+0x00e QuotaInfoOffset : 0 ‘’
+0x00f Flags : 0x2 ‘’
+0x010 ObjectCreateInfo : 0x00000001 _OBJECT_CREATE_INFORMATION
+0x010 QuotaBlockCharged : 0x00000001
+0x014 SecurityDescriptor : (null)
+0x018 Body : _QUAD
Any hints on how do I proceed further from here?
If I put breakpoint on the PointerCount (837d20c0), it gets lost as soon as
system hibernates.
Regards,
Suresh
Thanks Scott. However “!stacks 2 ndis!” didn’t give any useful outout, and “!pnptriage” showed following which I already knew:
Dumping IopRootDeviceNode (= 0x82f06188)
DevNode 0x856d8c20 for PDO 0x837ac370
InstancePath is “USB\VID_xxxx&PID_xxxx\c5004709”
ServiceName is “xxxx”
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_DRIVER_FAILED_PRIOR_UNLOAD
Inspecting the devnode I got:
0: kd> !devnode 0x856d8c20
DevNode 0x856d8c20 for PDO 0x837ac370
Parent 0x85100ea8 Sibling 0000000000 Child 0000000000
InstancePath is “USB\VID_xxxx&PID_xxxx\c5004709”
ServiceName is “xxxx”
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
StateHistory[00] = DeviceNodeUninitialized (0x301)
StateHistory[19] = Unknown State (0x0)
StateHistory[18] = Unknown State (0x0)
StateHistory[17] = Unknown State (0x0)
StateHistory[16] = Unknown State (0x0)
StateHistory[15] = Unknown State (0x0)
StateHistory[14] = Unknown State (0x0)
StateHistory[13] = Unknown State (0x0)
StateHistory[12] = Unknown State (0x0)
StateHistory[11] = Unknown State (0x0)
StateHistory[10] = Unknown State (0x0)
StateHistory[09] = Unknown State (0x0)
StateHistory[08] = Unknown State (0x0)
StateHistory[07] = Unknown State (0x0)
StateHistory[06] = Unknown State (0x0)
StateHistory[05] = Unknown State (0x0)
StateHistory[04] = Unknown State (0x0)
StateHistory[03] = Unknown State (0x0)
StateHistory[02] = Unknown State (0x0)
StateHistory[01] = Unknown State (0x0)
Flags (0x00002030) DNF_ENUMERATED, DNF_IDS_QUERIED,
DNF_HAS_PROBLEM
CapabilityFlags (0x00001c53) DeviceD1, DeviceD2,
Removable, UniqueID,
WakeFromD0, WakeFromD1,
WakeFromD2
Problem = CM_PROB_DRIVER_FAILED_PRIOR_UNLOAD
Hi,
I figured out, or rather stumbled upon, the solution to my issue. The problem is gone after I used WDF coinstaller version 1.9!
What is surprising is that I have been using WDK 6001 to build this driver and WDK 6001 has the coinstaller version 1.7 which is the same what Vista SP2 has inbox. So ideally there should not be a coinstaller required.
Anyway it solved the issue but I would be at peace if I could find out a direct correlation between the failure and some component in the earlier coinstaller.
Any hints on this are welcome.
Regards,
Suresh