DeviceTree bugchecks if my driver was loaded.

Hi,

I have a bugcheck while running DeviceTree (DDK tool supplied by OSR). The
bugcheck appears occurred in the OBJINFO.sys associated with the utility. I
don't have the symbol for OBJINFO so that I won't get the correct stack
trace. However, the active IRP and its current stack location were captured.

I see no obvious reason why my driver would trigger OBJINFO to bugcheck.
Could any body from OSR help?

Thanks,
Calvin

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com

kd> !thread
THREAD a4380da8 Cid 0328.0130 Teb: 7ffde000 Win32Thread: 9e25eeb0 RUNNING
on processor 0
IRP List:
9ef36f68: (0006,0094) Flags: 40000000 Mdl: 00000000
Not impersonating
DeviceMap 99f92fd0
Owning Process a43d6da8
Wait Start TickCount 468561 Elapsed Ticks: 0
Context Switch Count 189 LargeStack
UserTime 00:00:00.0015
KernelTime 00:00:00.0093
Start Address kernel32!BaseProcessStartThunk (0x77e8149f)
Win32 Start Address devicetree (0x0040eb56)
Stack Init ef085000 Current ef0842e4 Base ef085000 Limit ef080000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
ef0845d8 8082028c 00000003 eeab4000 8739f000
nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
ef084624 80820d11 00000003 809e78cc c021ce7c nt!KiBugCheckDebugBreak+0x19
(FPO: [Non-Fpo])
ef0849f0 808212af 00000050 8739f000 00000000 nt!KeBugCheck2+0x46d (FPO:
[Non-Fpo])
ef084a10 8084045e 00000050 8739f000 00000000 nt!KeBugCheckEx+0x19 (FPO:
[Non-Fpo])
ef084a60 8085efa8 00000000 8739f000 00000000 nt!MmAccessFault+0x758 (FPO:
[Non-Fpo])
ef084a60 eeab4da4 00000000 8739f000 00000000 nt!KiTrap0E+0xbc (FPO: [0,0]
TrapFrame @ ef084a78)
WARNING: Stack unwind information not available. Following frames may be
wrong.
ef084ba4 eeab558e 00000080 0012e898 0012d0f0 OBJINFO+0xda4
ef084c1c 80817171 860f2030 9ef36f68 809e72e4 OBJINFO+0x158e
ef084c2c 8095f110 a4380fb8 809e72cc 9ef36f68 nt!IopfCallDriver+0x31 (FPO:
[0,0,1])
ef084c50 808904d2 9ef36fd8 a418af90 9ef36f68 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
ef084c64 808911f6 860f2030 9ef36f68 a418af90
nt!IopSynchronousServiceTail+0x5e (FPO: [Non-Fpo])
ef084d00 8088a288 00000088 00000000 00000000 nt!IopXxxControlFile+0x5a6
(FPO: [Non-Fpo])
ef084d34 8085c3c4 00000088 00000000 00000000 nt!NtDeviceIoControlFile+0x28
(FPO: [Non-Fpo])
ef084d34 7ffe0304 00000088 00000000 00000000 nt!KiSystemService+0xc9 (FPO:
[0,0] TrapFrame @ ef084d64)
0012d0b0 77f75b1d 0040ddf0 00000088 00000000
SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
0012d0b4 0040ddf0 00000088 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
(FPO: [10,0,0])
0012fc58 00401c4a 00000088 012b0020 00392998 devicetree+0xddf0
012b0020 00220020 012b0240 00000001 00000006 devicetree+0x1c4a
00000001 00000000 00000000 00000000 00000000 0x220020

kd> !irp 9ef36f68
Irp is active with 1 stacks 1 is current (= 0x9ef36fd8)
No Mdl Thread a4380da8: Irp stack trace.
cmd flg cl Device File Completion-Context

[e, 0] 1 0 860f2030 a418af90 00000000-00000000
\Driver\OBJINFO
Args: 000017a8 00001388 cf532007 0012e898

Current stack location:
+0x000 DeviceIoControl :
+0x000 OutputBufferLength : 0x17a8
+0x004 InputBufferLength : 0x1388
+0x008 IoControlCode : 0xcf532007
+0x00c Type3InputBuffer : 0x0012e898

DeviceTree bugchecks if my driver was loaded.
Hi Calvin,

I’ll message you off list to try and figure out what’s going on.

-scott


Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Calvin Guan” wrote in message news:xxxxx@ntdev…
Hi,
I have a bugcheck while running DeviceTree (DDK tool supplied by OSR). The
bugcheck appears occurred in the OBJINFO.sys associated with the utility. I
don’t have the symbol for OBJINFO so that I won’t get the correct stack
trace. However, the active IRP and its current stack location were captured.
I see no obvious reason why my driver would trigger OBJINFO to bugcheck.
Could any body from OSR help?
Thanks,
Calvin
-
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
kd> !thread
THREAD a4380da8 Cid 0328.0130 Teb: 7ffde000 Win32Thread: 9e25eeb0 RUNNING
on processor 0
IRP List:
9ef36f68: (0006,0094) Flags: 40000000 Mdl: 00000000
Not impersonating
DeviceMap 99f92fd0
Owning Process a43d6da8
Wait Start TickCount 468561 Elapsed Ticks: 0
Context Switch Count 189 LargeStack
UserTime 00:00:00.0015
KernelTime 00:00:00.0093
Start Address kernel32!BaseProcessStartThunk (0x77e8149f)
Win32 Start Address devicetree (0x0040eb56)
Stack Init ef085000 Current ef0842e4 Base ef085000 Limit ef080000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
ef0845d8 8082028c 00000003 eeab4000 8739f000
nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
ef084624 80820d11 00000003 809e78cc c021ce7c nt!KiBugCheckDebugBreak+0x19
(FPO: [Non-Fpo])
ef0849f0 808212af 00000050 8739f000 00000000 nt!KeBugCheck2+0x46d (FPO:
[Non-Fpo])
ef084a10 8084045e 00000050 8739f000 00000000 nt!KeBugCheckEx+0x19 (FPO:
[Non-Fpo])
ef084a60 8085efa8 00000000 8739f000 00000000 nt!MmAccessFault+0x758 (FPO:
[Non-Fpo])
ef084a60 eeab4da4 00000000 8739f000 00000000 nt!KiTrap0E+0xbc (FPO: [0,0]
TrapFrame @ ef084a78)
WARNING: Stack unwind information not available. Following frames may be
wrong.
ef084ba4 eeab558e 00000080 0012e898 0012d0f0 OBJINFO+0xda4
ef084c1c 80817171 860f2030 9ef36f68 809e72e4 OBJINFO+0x158e
ef084c2c 8095f110 a4380fb8 809e72cc 9ef36f68 nt!IopfCallDriver+0x31 (FPO:
[0,0,1])
ef084c50 808904d2 9ef36fd8 a418af90 9ef36f68 nt!IovCallDriver+0x9e (FPO:
[Non-Fpo])
ef084c64 808911f6 860f2030 9ef36f68 a418af90
nt!IopSynchronousServiceTail+0x5e (FPO: [Non-Fpo])
ef084d00 8088a288 00000088 00000000 00000000 nt!IopXxxControlFile+0x5a6
(FPO: [Non-Fpo])
ef084d34 8085c3c4 00000088 00000000 00000000 nt!NtDeviceIoControlFile+0x28
(FPO: [Non-Fpo])
ef084d34 7ffe0304 00000088 00000000 00000000 nt!KiSystemService+0xc9 (FPO:
[0,0] TrapFrame @ ef084d64)
0012d0b0 77f75b1d 0040ddf0 00000088 00000000
SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
0012d0b4 0040ddf0 00000088 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
(FPO: [10,0,0])
0012fc58 00401c4a 00000088 012b0020 00392998 devicetree+0xddf0
012b0020 00220020 012b0240 00000001 00000006 devicetree+0x1c4a
00000001 00000000 00000000 00000000 00000000 0x220020
kd> !irp 9ef36f68
Irp is active with 1 stacks 1 is current (= 0x9ef36fd8)
No Mdl Thread a4380da8: Irp stack trace.
cmd flg cl Device File Completion-Context
>[e, 0] 1 0 860f2030 a418af90 00000000-00000000
\Driver\OBJINFO
Args: 000017a8 00001388 cf532007 0012e898
Current stack location:
+0x000 DeviceIoControl :
+0x000 OutputBufferLength : 0x17a8
+0x004 InputBufferLength : 0x1388
+0x008 IoControlCode : 0xcf532007
+0x00c Type3InputBuffer : 0x0012e898

Scott,

could you post resume when figured out? I also encountered similar bugcheck in the past; several times. One was related to VMware parallel driver which created device object or security descriptor (I forgot details) an unusual way and objinfo crashed when tried to examine object header which wasn’t present.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Scott Noone[SMTP:xxxxx@osr.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, October 19, 2004 10:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DeviceTree bugchecks if my driver was loaded.

DeviceTree bugchecks if my driver was loaded.
Hi Calvin,

I’ll message you off list to try and figure out what’s going on.

-scott


Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Calvin Guan” wrote in message news:xxxxx@ntdev…
> Hi,
> I have a bugcheck while running DeviceTree (DDK tool supplied by OSR). The
> bugcheck appears occurred in the OBJINFO.sys associated with the utility. I
> don’t have the symbol for OBJINFO so that I won’t get the correct stack
> trace. However, the active IRP and its current stack location were captured.
> I see no obvious reason why my driver would trigger OBJINFO to bugcheck.
> Could any body from OSR help?
> Thanks,
> Calvin
> -
> Calvin Guan Software Engineer
> ATI Technologies Inc. www.ati.com
> kd> !thread
> THREAD a4380da8 Cid 0328.0130 Teb: 7ffde000 Win32Thread: 9e25eeb0 RUNNING
> on processor 0
> IRP List:
> 9ef36f68: (0006,0094) Flags: 40000000 Mdl: 00000000
> Not impersonating
> DeviceMap 99f92fd0
> Owning Process a43d6da8
> Wait Start TickCount 468561 Elapsed Ticks: 0
> Context Switch Count 189 LargeStack
> UserTime 00:00:00.0015
> KernelTime 00:00:00.0093
> Start Address kernel32!BaseProcessStartThunk (0x77e8149f)
> Win32 Start Address devicetree (0x0040eb56)
> Stack Init ef085000 Current ef0842e4 Base ef085000 Limit ef080000 Call 0
> Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
> ChildEBP RetAddr Args to Child
> ef0845d8 8082028c 00000003 eeab4000 8739f000
> nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> ef084624 80820d11 00000003 809e78cc c021ce7c nt!KiBugCheckDebugBreak+0x19
> (FPO: [Non-Fpo])
> ef0849f0 808212af 00000050 8739f000 00000000 nt!KeBugCheck2+0x46d (FPO:
> [Non-Fpo])
> ef084a10 8084045e 00000050 8739f000 00000000 nt!KeBugCheckEx+0x19 (FPO:
> [Non-Fpo])
> ef084a60 8085efa8 00000000 8739f000 00000000 nt!MmAccessFault+0x758 (FPO:
> [Non-Fpo])
> ef084a60 eeab4da4 00000000 8739f000 00000000 nt!KiTrap0E+0xbc (FPO: [0,0]
> TrapFrame @ ef084a78)
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> ef084ba4 eeab558e 00000080 0012e898 0012d0f0 OBJINFO+0xda4
> ef084c1c 80817171 860f2030 9ef36f68 809e72e4 OBJINFO+0x158e
> ef084c2c 8095f110 a4380fb8 809e72cc 9ef36f68 nt!IopfCallDriver+0x31 (FPO:
> [0,0,1])
> ef084c50 808904d2 9ef36fd8 a418af90 9ef36f68 nt!IovCallDriver+0x9e (FPO:
> [Non-Fpo])
> ef084c64 808911f6 860f2030 9ef36f68 a418af90
> nt!IopSynchronousServiceTail+0x5e (FPO: [Non-Fpo])
> ef084d00 8088a288 00000088 00000000 00000000 nt!IopXxxControlFile+0x5a6
> (FPO: [Non-Fpo])
> ef084d34 8085c3c4 00000088 00000000 00000000 nt!NtDeviceIoControlFile+0x28
> (FPO: [Non-Fpo])
> ef084d34 7ffe0304 00000088 00000000 00000000 nt!KiSystemService+0xc9 (FPO:
> [0,0] TrapFrame @ ef084d64)
> 0012d0b0 77f75b1d 0040ddf0 00000088 00000000
> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
> 0012d0b4 0040ddf0 00000088 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
> (FPO: [10,0,0])>
> 0012fc58 00401c4a 00000088 012b0020 00392998 devicetree+0xddf0
> 012b0020 00220020 012b0240 00000001 00000006 devicetree+0x1c4a
> 00000001 00000000 00000000 00000000 00000000 0x220020
> kd> !irp 9ef36f68
> Irp is active with 1 stacks 1 is current (= 0x9ef36fd8)
> No Mdl Thread a4380da8: Irp stack trace.
> cmd flg cl Device File Completion-Context
> >[e, 0] 1 0 860f2030 a418af90 00000000-00000000
> \Driver\OBJINFO
> Args: 000017a8 00001388 cf532007 0012e898
> Current stack location:
> +0x000 DeviceIoControl :
> +0x000 OutputBufferLength : 0x17a8
> +0x004 InputBufferLength : 0x1388
> +0x008 IoControlCode : 0xcf532007
> +0x00c Type3InputBuffer : 0x0012e898
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Hi,

Do you still see these problems in the latest version on OSR Online? There
were three VMWare drivers (vm86, vmparport, and hcmon) that built their own
security descriptors and slammed them into DeviceObject->SecurityDescriptor,
which ended up causing the I/O manager to freak when we called
ObReferenceObjectByPointer on the device object (I believe that the latest
versions don’t do this anymore though). We added a workaround for this a
while ago (we simply ignore displaying any info about these drivers) so this
particular problem should have been fixed a couple of versions ago.

If you’re still having problems with the VMWare drivers or any other
problems please let me know.

-scott


Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
Scott,

could you post resume when figured out? I also encountered similar bugcheck
in the past; several times. One was related to VMware parallel driver which
created device object or security descriptor (I forgot details) an unusual
way and objinfo crashed when tried to examine object header which wasn’t
present.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Scott Noone[SMTP:xxxxx@osr.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, October 19, 2004 10:44 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] DeviceTree bugchecks if my driver was loaded.
>
> DeviceTree bugchecks if my driver was loaded.
> Hi Calvin,
>
> I’ll message you off list to try and figure out what’s going on.
>
> -scott
>
> –
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Calvin Guan” wrote in message news:xxxxx@ntdev…
> Hi,
> I have a bugcheck while running DeviceTree (DDK tool supplied by OSR). The
> bugcheck appears occurred in the OBJINFO.sys associated with the utility.
> I
> don’t have the symbol for OBJINFO so that I won’t get the correct stack
> trace. However, the active IRP and its current stack location were
> captured.
> I see no obvious reason why my driver would trigger OBJINFO to bugcheck.
> Could any body from OSR help?
> Thanks,
> Calvin
> -
> Calvin Guan Software Engineer
> ATI Technologies Inc. www.ati.com
> kd> !thread
> THREAD a4380da8 Cid 0328.0130 Teb: 7ffde000 Win32Thread: 9e25eeb0
> RUNNING
> on processor 0
> IRP List:
> 9ef36f68: (0006,0094) Flags: 40000000 Mdl: 00000000
> Not impersonating
> DeviceMap 99f92fd0
> Owning Process a43d6da8
> Wait Start TickCount 468561 Elapsed Ticks: 0
> Context Switch Count 189 LargeStack
> UserTime 00:00:00.0015
> KernelTime 00:00:00.0093
> Start Address kernel32!BaseProcessStartThunk (0x77e8149f)
> Win32 Start Address devicetree (0x0040eb56)
> Stack Init ef085000 Current ef0842e4 Base ef085000 Limit ef080000 Call 0
> Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
> ChildEBP RetAddr Args to Child
> ef0845d8 8082028c 00000003 eeab4000 8739f000
> nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> ef084624 80820d11 00000003 809e78cc c021ce7c nt!KiBugCheckDebugBreak+0x19
> (FPO: [Non-Fpo])
> ef0849f0 808212af 00000050 8739f000 00000000 nt!KeBugCheck2+0x46d (FPO:
> [Non-Fpo])
> ef084a10 8084045e 00000050 8739f000 00000000 nt!KeBugCheckEx+0x19 (FPO:
> [Non-Fpo])
> ef084a60 8085efa8 00000000 8739f000 00000000 nt!MmAccessFault+0x758 (FPO:
> [Non-Fpo])
> ef084a60 eeab4da4 00000000 8739f000 00000000 nt!KiTrap0E+0xbc (FPO: [0,0]
> TrapFrame @ ef084a78)
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> ef084ba4 eeab558e 00000080 0012e898 0012d0f0 OBJINFO+0xda4
> ef084c1c 80817171 860f2030 9ef36f68 809e72e4 OBJINFO+0x158e
> ef084c2c 8095f110 a4380fb8 809e72cc 9ef36f68 nt!IopfCallDriver+0x31 (FPO:
> [0,0,1])
> ef084c50 808904d2 9ef36fd8 a418af90 9ef36f68 nt!IovCallDriver+0x9e (FPO:
> [Non-Fpo])
> ef084c64 808911f6 860f2030 9ef36f68 a418af90
> nt!IopSynchronousServiceTail+0x5e (FPO: [Non-Fpo])
> ef084d00 8088a288 00000088 00000000 00000000 nt!IopXxxControlFile+0x5a6
> (FPO: [Non-Fpo])
> ef084d34 8085c3c4 00000088 00000000 00000000 nt!NtDeviceIoControlFile+0x28
> (FPO: [Non-Fpo])
> ef084d34 7ffe0304 00000088 00000000 00000000 nt!KiSystemService+0xc9 (FPO:
> [0,0] TrapFrame @ ef084d64)
> 0012d0b0 77f75b1d 0040ddf0 00000088 00000000
> SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
> 0012d0b4 0040ddf0 00000088 00000000 00000000
> ntdll!ZwDeviceIoControlFile+0xc
> (FPO: [10,0,0])>
> 0012fc58 00401c4a 00000088 012b0020 00392998 devicetree+0xddf0
> 012b0020 00220020 012b0240 00000001 00000006 devicetree+0x1c4a
> 00000001 00000000 00000000 00000000 00000000 0x220020
> kd> !irp 9ef36f68
> Irp is active with 1 stacks 1 is current (= 0x9ef36fd8)
> No Mdl Thread a4380da8: Irp stack trace.
> cmd flg cl Device File Completion-Context
> >[e, 0] 1 0 860f2030 a418af90 00000000-00000000
> \Driver\OBJINFO
> Args: 000017a8 00001388 cf532007 0012e898
> Current stack location:
> +0x000 DeviceIoControl :
> +0x000 OutputBufferLength : 0x17a8
> +0x004 InputBufferLength : 0x1388
> +0x008 IoControlCode : 0xcf532007
> +0x00c Type3InputBuffer : 0x0012e898
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

It is several months I ago saw the last problem. Since then I updated VMware so maybe it helped; I knew only about vmparport problem with security descriptor (had it disabled) and not about their other drivers.

On the other hand, I don’t use DeviceTree too often and problem was rare even with buggy drivers. Currently I use 2.10 version which seems as latest one. Surprisingly, it displays info about VMware drivers.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Scott Noone[SMTP:xxxxx@osr.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, October 19, 2004 11:16 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DeviceTree bugchecks if my driver was loaded.

Hi,

Do you still see these problems in the latest version on OSR Online? There
were three VMWare drivers (vm86, vmparport, and hcmon) that built their own
security descriptors and slammed them into DeviceObject->SecurityDescriptor,
which ended up causing the I/O manager to freak when we called
ObReferenceObjectByPointer on the device object (I believe that the latest
versions don’t do this anymore though). We added a workaround for this a
while ago (we simply ignore displaying any info about these drivers) so this
particular problem should have been fixed a couple of versions ago.

If you’re still having problems with the VMWare drivers or any other
problems please let me know.

-scott


Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
> Scott,
>
> could you post resume when figured out? I also encountered similar bugcheck
> in the past; several times. One was related to VMware parallel driver which
> created device object or security descriptor (I forgot details) an unusual
> way and objinfo crashed when tried to examine object header which wasn’t
> present.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> > ----------
> > From:
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> > on behalf of Scott Noone[SMTP:xxxxx@osr.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Tuesday, October 19, 2004 10:44 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] DeviceTree bugchecks if my driver was loaded.
> >
> > DeviceTree bugchecks if my driver was loaded.
> > Hi Calvin,
> >
> > I’ll message you off list to try and figure out what’s going on.
> >
> > -scott
> >
> > –
> > Scott Noone
> > Software Engineer
> > OSR Open Systems Resources, Inc.
> > http://www.osronline.com
> >
> > “Calvin Guan” wrote in message news:xxxxx@ntdev…
> > Hi,
> > I have a bugcheck while running DeviceTree (DDK tool supplied by OSR). The
> > bugcheck appears occurred in the OBJINFO.sys associated with the utility.
> > I
> > don’t have the symbol for OBJINFO so that I won’t get the correct stack
> > trace. However, the active IRP and its current stack location were
> > captured.
> > I see no obvious reason why my driver would trigger OBJINFO to bugcheck.
> > Could any body from OSR help?
> > Thanks,
> > Calvin
> > -
> > Calvin Guan Software Engineer
> > ATI Technologies Inc. www.ati.com
> > kd> !thread
> > THREAD a4380da8 Cid 0328.0130 Teb: 7ffde000 Win32Thread: 9e25eeb0
> > RUNNING
> > on processor 0
> > IRP List:
> > 9ef36f68: (0006,0094) Flags: 40000000 Mdl: 00000000
> > Not impersonating
> > DeviceMap 99f92fd0
> > Owning Process a43d6da8
> > Wait Start TickCount 468561 Elapsed Ticks: 0
> > Context Switch Count 189 LargeStack>
> > UserTime 00:00:00.0015
> > KernelTime 00:00:00.0093
> > Start Address kernel32!BaseProcessStartThunk (0x77e8149f)
> > Win32 Start Address devicetree (0x0040eb56)
> > Stack Init ef085000 Current ef0842e4 Base ef085000 Limit ef080000 Call 0
> > Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
> > ChildEBP RetAddr Args to Child
> > ef0845d8 8082028c 00000003 eeab4000 8739f000
> > nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> > ef084624 80820d11 00000003 809e78cc c021ce7c nt!KiBugCheckDebugBreak+0x19
> > (FPO: [Non-Fpo])
> > ef0849f0 808212af 00000050 8739f000 00000000 nt!KeBugCheck2+0x46d (FPO:
> > [Non-Fpo])
> > ef084a10 8084045e 00000050 8739f000 00000000 nt!KeBugCheckEx+0x19 (FPO:
> > [Non-Fpo])
> > ef084a60 8085efa8 00000000 8739f000 00000000 nt!MmAccessFault+0x758 (FPO:
> > [Non-Fpo])
> > ef084a60 eeab4da4 00000000 8739f000 00000000 nt!KiTrap0E+0xbc (FPO: [0,0]
> > TrapFrame @ ef084a78)
> > WARNING: Stack unwind information not available. Following frames may be
> > wrong.
> > ef084ba4 eeab558e 00000080 0012e898 0012d0f0 OBJINFO+0xda4
> > ef084c1c 80817171 860f2030 9ef36f68 809e72e4 OBJINFO+0x158e
> > ef084c2c 8095f110 a4380fb8 809e72cc 9ef36f68 nt!IopfCallDriver+0x31 (FPO:
> > [0,0,1])
> > ef084c50 808904d2 9ef36fd8 a418af90 9ef36f68 nt!IovCallDriver+0x9e (FPO:
> > [Non-Fpo])
> > ef084c64 808911f6 860f2030 9ef36f68 a418af90
> > nt!IopSynchronousServiceTail+0x5e (FPO: [Non-Fpo])
> > ef084d00 8088a288 00000088 00000000 00000000 nt!IopXxxControlFile+0x5a6
> > (FPO: [Non-Fpo])
> > ef084d34 8085c3c4 00000088 00000000 00000000 nt!NtDeviceIoControlFile+0x28
> > (FPO: [Non-Fpo])
> > ef084d34 7ffe0304 00000088 00000000 00000000 nt!KiSystemService+0xc9 (FPO:
> > [0,0] TrapFrame @ ef084d64)
> > 0012d0b0 77f75b1d 0040ddf0 00000088 00000000
> > SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
> > 0012d0b4 0040ddf0 00000088 00000000 00000000
> > ntdll!ZwDeviceIoControlFile+0xc
> > (FPO: [10,0,0])>
> > 0012fc58 00401c4a 00000088 012b0020 00392998 devicetree+0xddf0
> > 012b0020 00220020 012b0240 00000001 00000006 devicetree+0x1c4a
> > 00000001 00000000 00000000 00000000 00000000 0x220020
> > kd> !irp 9ef36f68
> > Irp is active with 1 stacks 1 is current (= 0x9ef36fd8)
> > No Mdl Thread a4380da8: Irp stack trace.
> > cmd flg cl Device File Completion-Context
> > >[e, 0] 1 0 860f2030 a418af90 00000000-00000000
> > \Driver\OBJINFO
> > Args: 000017a8 00001388 cf532007 0012e898
> > Current stack location:
> > +0x000 DeviceIoControl :
> > +0x000 OutputBufferLength : 0x17a8
> > +0x004 InputBufferLength : 0x1388
> > +0x008 IoControlCode : 0xcf532007
> > +0x00c Type3InputBuffer : 0x0012e898
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@upek.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

> Surprisingly, it displays info about VMware drivers

Hmm, that IS weird. I’ll have to check out when we started filtering these
out.

Thanks,

-scott


Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
It is several months I ago saw the last problem. Since then I updated VMware
so maybe it helped; I knew only about vmparport problem with security
descriptor (had it disabled) and not about their other drivers.

On the other hand, I don’t use DeviceTree too often and problem was rare
even with buggy drivers. Currently I use 2.10 version which seems as latest
one. Surprisingly, it displays info about VMware drivers.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Scott Noone[SMTP:xxxxx@osr.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, October 19, 2004 11:16 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] DeviceTree bugchecks if my driver was loaded.
>
> Hi,
>
> Do you still see these problems in the latest version on OSR Online? There
> were three VMWare drivers (vm86, vmparport, and hcmon) that built their
> own
> security descriptors and slammed them into
> DeviceObject->SecurityDescriptor,
> which ended up causing the I/O manager to freak when we called
> ObReferenceObjectByPointer on the device object (I believe that the latest
> versions don’t do this anymore though). We added a workaround for this a
> while ago (we simply ignore displaying any info about these drivers) so
> this
> particular problem should have been fixed a couple of versions ago.
>
> If you’re still having problems with the VMWare drivers or any other
> problems please let me know.
>
> -scott
>
> –
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
> Scott,
>
> could you post resume when figured out? I also encountered similar
> bugcheck
> in the past; several times. One was related to VMware parallel driver
> which
> created device object or security descriptor (I forgot details) an unusual
> way and objinfo crashed when tried to examine object header which wasn’t
> present.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> > ----------
> > From:
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> > on behalf of Scott Noone[SMTP:xxxxx@osr.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Tuesday, October 19, 2004 10:44 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] DeviceTree bugchecks if my driver was loaded.
> >
> > DeviceTree bugchecks if my driver was loaded.
> > Hi Calvin,
> >
> > I’ll message you off list to try and figure out what’s going on.
> >
> > -scott
> >
> > –
> > Scott Noone
> > Software Engineer
> > OSR Open Systems Resources, Inc.
> > http://www.osronline.com
> >
> > “Calvin Guan” wrote in message news:xxxxx@ntdev…
> > Hi,
> > I have a bugcheck while running DeviceTree (DDK tool supplied by OSR).
> > The
> > bugcheck appears occurred in the OBJINFO.sys associated with the
> > utility.
> > I
> > don’t have the symbol for OBJINFO so that I won’t get the correct stack
> > trace. However, the active IRP and its current stack location were
> > captured.
> > I see no obvious reason why my driver would trigger OBJINFO to bugcheck.
> > Could any body from OSR help?
> > Thanks,
> > Calvin
> > -
> > Calvin Guan Software Engineer
> > ATI Technologies Inc. www.ati.com
> > kd> !thread
> > THREAD a4380da8 Cid 0328.0130 Teb: 7ffde000 Win32Thread: 9e25eeb0
> > RUNNING
> > on processor 0
> > IRP List:
> > 9ef36f68: (0006,0094) Flags: 40000000 Mdl: 00000000
> > Not impersonating
> > DeviceMap 99f92fd0
> > Owning Process a43d6da8
> > Wait Start TickCount 468561 Elapsed Ticks: 0
> > Context Switch Count 189 LargeStack>
> > UserTime 00:00:00.0015
> > KernelTime 00:00:00.0093
> > Start Address kernel32!BaseProcessStartThunk (0x77e8149f)
> > Win32 Start Address devicetree (0x0040eb56)
> > Stack Init ef085000 Current ef0842e4 Base ef085000 Limit ef080000 Call 0
> > Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
> > ChildEBP RetAddr Args to Child
> > ef0845d8 8082028c 00000003 eeab4000 8739f000
> > nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> > ef084624 80820d11 00000003 809e78cc c021ce7c
> > nt!KiBugCheckDebugBreak+0x19
> > (FPO: [Non-Fpo])
> > ef0849f0 808212af 00000050 8739f000 00000000 nt!KeBugCheck2+0x46d (FPO:
> > [Non-Fpo])
> > ef084a10 8084045e 00000050 8739f000 00000000 nt!KeBugCheckEx+0x19 (FPO:
> > [Non-Fpo])
> > ef084a60 8085efa8 00000000 8739f000 00000000 nt!MmAccessFault+0x758
> > (FPO:
> > [Non-Fpo])
> > ef084a60 eeab4da4 00000000 8739f000 00000000 nt!KiTrap0E+0xbc (FPO:
> > [0,0]
> > TrapFrame @ ef084a78)
> > WARNING: Stack unwind information not available. Following frames may be
> > wrong.
> > ef084ba4 eeab558e 00000080 0012e898 0012d0f0 OBJINFO+0xda4
> > ef084c1c 80817171 860f2030 9ef36f68 809e72e4 OBJINFO+0x158e
> > ef084c2c 8095f110 a4380fb8 809e72cc 9ef36f68 nt!IopfCallDriver+0x31
> > (FPO:
> > [0,0,1])
> > ef084c50 808904d2 9ef36fd8 a418af90 9ef36f68 nt!IovCallDriver+0x9e (FPO:
> > [Non-Fpo])
> > ef084c64 808911f6 860f2030 9ef36f68 a418af90
> > nt!IopSynchronousServiceTail+0x5e (FPO: [Non-Fpo])
> > ef084d00 8088a288 00000088 00000000 00000000 nt!IopXxxControlFile+0x5a6
> > (FPO: [Non-Fpo])
> > ef084d34 8085c3c4 00000088 00000000 00000000
> > nt!NtDeviceIoControlFile+0x28
> > (FPO: [Non-Fpo])
> > ef084d34 7ffe0304 00000088 00000000 00000000 nt!KiSystemService+0xc9
> > (FPO:
> > [0,0] TrapFrame @ ef084d64)
> > 0012d0b0 77f75b1d 0040ddf0 00000088 00000000
> > SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
> > 0012d0b4 0040ddf0 00000088 00000000 00000000
> > ntdll!ZwDeviceIoControlFile+0xc
> > (FPO: [10,0,0])>
> > 0012fc58 00401c4a 00000088 012b0020 00392998 devicetree+0xddf0
> > 012b0020 00220020 012b0240 00000001 00000006 devicetree+0x1c4a
> > 00000001 00000000 00000000 00000000 00000000 0x220020
> > kd> !irp 9ef36f68
> > Irp is active with 1 stacks 1 is current (= 0x9ef36fd8)
> > No Mdl Thread a4380da8: Irp stack trace.
> > cmd flg cl Device File Completion-Context
> > >[e, 0] 1 0 860f2030 a418af90 00000000-00000000
> > \Driver\OBJINFO
> > Args: 000017a8 00001388 cf532007 0012e898
> > Current stack location:
> > +0x000 DeviceIoControl :
> > +0x000 OutputBufferLength : 0x17a8
> > +0x004 InputBufferLength : 0x1388
> > +0x008 IoControlCode : 0xcf532007
> > +0x00c Type3InputBuffer : 0x0012e898
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@upek.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

> From: xxxxx@lists.osr.com

[mailto:xxxxx@lists.osr.com]On Behalf Of Scott Noone
Sent: Tuesday, October 19, 2004 2:17 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DeviceTree bugchecks if my driver was loaded.

Hi,

Do you still see these problems in the latest version on OSR
Online? There
were three VMWare drivers (vm86, vmparport, and hcmon) that
built their own
security descriptors and slammed them into
DeviceObject->SecurityDescriptor,
which ended up causing the I/O manager to freak when we called
ObReferenceObjectByPointer on the device object (I believe
that the latest
versions don’t do this anymore though).

Yes, It is fixed in the latest released versions (VMware Workstation 4.5.2,
GSX 3.1).

We added a workaround for this a while ago

I would appreciate good bug reports on VMware products, especially on kernel
drivers.

Dmitriy Budko, VMware
xxxxx@vmware.com

We are up to V2.15 in devicetree. It will be posted up on the website as
soon as possible.


Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Scott Noone” wrote in message news:xxxxx@ntdev…
>> Surprisingly, it displays info about VMware drivers
>
> Hmm, that IS weird. I’ll have to check out when we started filtering these
> out.
>
> Thanks,
>
> -scott
>
> –
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
> It is several months I ago saw the last problem. Since then I updated
> VMware so maybe it helped; I knew only about vmparport problem with
> security descriptor (had it disabled) and not about their other drivers.
>
> On the other hand, I don’t use DeviceTree too often and problem was rare
> even with buggy drivers. Currently I use 2.10 version which seems as
> latest one. Surprisingly, it displays info about VMware drivers.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>> ----------
>> From:
>> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>> on behalf of Scott Noone[SMTP:xxxxx@osr.com]
>> Reply To: Windows System Software Devs Interest List
>> Sent: Tuesday, October 19, 2004 11:16 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] DeviceTree bugchecks if my driver was loaded.
>>
>> Hi,
>>
>> Do you still see these problems in the latest version on OSR Online?
>> There
>> were three VMWare drivers (vm86, vmparport, and hcmon) that built their
>> own
>> security descriptors and slammed them into
>> DeviceObject->SecurityDescriptor,
>> which ended up causing the I/O manager to freak when we called
>> ObReferenceObjectByPointer on the device object (I believe that the
>> latest
>> versions don’t do this anymore though). We added a workaround for this a
>> while ago (we simply ignore displaying any info about these drivers) so
>> this
>> particular problem should have been fixed a couple of versions ago.
>>
>> If you’re still having problems with the VMWare drivers or any other
>> problems please let me know.
>>
>> -scott
>>
>> –
>> Scott Noone
>> Software Engineer
>> OSR Open Systems Resources, Inc.
>> http://www.osronline.com
>>
>>
>> “Michal Vodicka” wrote in message
>> news:xxxxx@ntdev…
>> Scott,
>>
>> could you post resume when figured out? I also encountered similar
>> bugcheck
>> in the past; several times. One was related to VMware parallel driver
>> which
>> created device object or security descriptor (I forgot details) an
>> unusual
>> way and objinfo crashed when tried to examine object header which wasn’t
>> present.
>>
>> Best regards,
>>
>> Michal Vodicka
>> UPEK, Inc.
>> [xxxxx@upek.com, http://www.upek.com]
>>
>>
>> > ----------
>> > From:
>> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>> > on behalf of Scott Noone[SMTP:xxxxx@osr.com]
>> > Reply To: Windows System Software Devs Interest List
>> > Sent: Tuesday, October 19, 2004 10:44 PM
>> > To: Windows System Software Devs Interest List
>> > Subject: Re:[ntdev] DeviceTree bugchecks if my driver was loaded.
>> >
>> > DeviceTree bugchecks if my driver was loaded.
>> > Hi Calvin,
>> >
>> > I’ll message you off list to try and figure out what’s going on.
>> >
>> > -scott
>> >
>> > –
>> > Scott Noone
>> > Software Engineer
>> > OSR Open Systems Resources, Inc.
>> > http://www.osronline.com
>> >
>> > “Calvin Guan” wrote in message news:xxxxx@ntdev…
>> > Hi,
>> > I have a bugcheck while running DeviceTree (DDK tool supplied by OSR).
>> > The
>> > bugcheck appears occurred in the OBJINFO.sys associated with the
>> > utility.
>> > I
>> > don’t have the symbol for OBJINFO so that I won’t get the correct stack
>> > trace. However, the active IRP and its current stack location were
>> > captured.
>> > I see no obvious reason why my driver would trigger OBJINFO to
>> > bugcheck.
>> > Could any body from OSR help?
>> > Thanks,
>> > Calvin
>> > -
>> > Calvin Guan Software Engineer
>> > ATI Technologies Inc. www.ati.com
>> > kd> !thread
>> > THREAD a4380da8 Cid 0328.0130 Teb: 7ffde000 Win32Thread: 9e25eeb0
>> > RUNNING
>> > on processor 0
>> > IRP List:
>> > 9ef36f68: (0006,0094) Flags: 40000000 Mdl: 00000000
>> > Not impersonating
>> > DeviceMap 99f92fd0
>> > Owning Process a43d6da8
>> > Wait Start TickCount 468561 Elapsed Ticks: 0
>> > Context Switch Count 189 LargeStack>
>> > UserTime 00:00:00.0015
>> > KernelTime 00:00:00.0093
>> > Start Address kernel32!BaseProcessStartThunk (0x77e8149f)
>> > Win32 Start Address devicetree (0x0040eb56)
>> > Stack Init ef085000 Current ef0842e4 Base ef085000 Limit ef080000 Call
>> > 0
>> > Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16
>> > ChildEBP RetAddr Args to Child
>> > ef0845d8 8082028c 00000003 eeab4000 8739f000
>> > nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
>> > ef084624 80820d11 00000003 809e78cc c021ce7c
>> > nt!KiBugCheckDebugBreak+0x19
>> > (FPO: [Non-Fpo])
>> > ef0849f0 808212af 00000050 8739f000 00000000 nt!KeBugCheck2+0x46d (FPO:
>> > [Non-Fpo])
>> > ef084a10 8084045e 00000050 8739f000 00000000 nt!KeBugCheckEx+0x19 (FPO:
>> > [Non-Fpo])
>> > ef084a60 8085efa8 00000000 8739f000 00000000 nt!MmAccessFault+0x758
>> > (FPO:
>> > [Non-Fpo])
>> > ef084a60 eeab4da4 00000000 8739f000 00000000 nt!KiTrap0E+0xbc (FPO:
>> > [0,0]
>> > TrapFrame @ ef084a78)
>> > WARNING: Stack unwind information not available. Following frames may
>> > be
>> > wrong.
>> > ef084ba4 eeab558e 00000080 0012e898 0012d0f0 OBJINFO+0xda4
>> > ef084c1c 80817171 860f2030 9ef36f68 809e72e4 OBJINFO+0x158e
>> > ef084c2c 8095f110 a4380fb8 809e72cc 9ef36f68 nt!IopfCallDriver+0x31
>> > (FPO:
>> > [0,0,1])
>> > ef084c50 808904d2 9ef36fd8 a418af90 9ef36f68 nt!IovCallDriver+0x9e
>> > (FPO:
>> > [Non-Fpo])
>> > ef084c64 808911f6 860f2030 9ef36f68 a418af90
>> > nt!IopSynchronousServiceTail+0x5e (FPO: [Non-Fpo])
>> > ef084d00 8088a288 00000088 00000000 00000000 nt!IopXxxControlFile+0x5a6
>> > (FPO: [Non-Fpo])
>> > ef084d34 8085c3c4 00000088 00000000 00000000
>> > nt!NtDeviceIoControlFile+0x28
>> > (FPO: [Non-Fpo])
>> > ef084d34 7ffe0304 00000088 00000000 00000000 nt!KiSystemService+0xc9
>> > (FPO:
>> > [0,0] TrapFrame @ ef084d64)
>> > 0012d0b0 77f75b1d 0040ddf0 00000088 00000000
>> > SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
>> > 0012d0b4 0040ddf0 00000088 00000000 00000000
>> > ntdll!ZwDeviceIoControlFile+0xc
>> > (FPO: [10,0,0])>
>> > 0012fc58 00401c4a 00000088 012b0020 00392998 devicetree+0xddf0
>> > 012b0020 00220020 012b0240 00000001 00000006 devicetree+0x1c4a
>> > 00000001 00000000 00000000 00000000 00000000 0x220020
>> > kd> !irp 9ef36f68
>> > Irp is active with 1 stacks 1 is current (= 0x9ef36fd8)
>> > No Mdl Thread a4380da8: Irp stack trace.
>> > cmd flg cl Device File Completion-Context
>> > >[e, 0] 1 0 860f2030 a418af90 00000000-00000000
>> > \Driver\OBJINFO
>> > Args: 000017a8 00001388 cf532007 0012e898
>> > Current stack location:
>> > +0x000 DeviceIoControl :
>> > +0x000 OutputBufferLength : 0x17a8
>> > +0x004 InputBufferLength : 0x1388
>> > +0x008 IoControlCode : 0xcf532007
>> > +0x00c Type3InputBuffer : 0x0012e898
>> >
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as: xxxxx@upek.com
>> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>> >
>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@upek.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
>