WinDbg/DebugView extra crashes?

James_Bellinger · January 23, 2012, 12:22am

On my test virtual machine (Windows 7 64-bit on VirtualBox), I’ve
noticed lately that
my driver does not crash the system if I don’t have Sysinternals
DebugView attached.
Sometimes the same seems to be true of WinDbg – Are there extra checks
that only
occur when something is listening to KdPrint() output, or if not, what
might the reason be for this?

Thanks

James

Doron_Holan · January 23, 2012, 12:30am

The retrieval and copying of the debugger strings can slow down the system and change timings. That is not to say it isn’t a bug, rather this makes your bugs less or more likely

d

debt from my phone

From: James Bellinger
Sent: 1/22/2012 9:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WinDbg/DebugView extra crashes?

On my test virtual machine (Windows 7 64-bit on VirtualBox), I’ve
noticed lately that
my driver does not crash the system if I don’t have Sysinternals
DebugView attached.
Sometimes the same seems to be true of WinDbg – Are there extra checks
that only
occur when something is listening to KdPrint() output, or if not, what
might the reason be for this?

Thanks

James

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Thomas_Divine · January 23, 2012, 12:31am

It there are crashes with WinDbg running - analyze them for heaven’s sake!

If you are running the checked build of your driver, then you just might
have a flaw in one of your KdPrint statements. Perhaps bogus formatting
statement, etc. Flaws in your KdPrint’s wouldn’t appear if you are running
he free build of your driver.

In any case: Get crash -> Find YOUR bug. Don’t blame it on WinDbg or
DebugView.

Thomas F. Divine
http://www.pcausa.com

From: “James Bellinger”
Sent: Monday, January 23, 2012 12:21 AM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] WinDbg/DebugView extra crashes?

> On my test virtual machine (Windows 7 64-bit on VirtualBox), I’ve noticed
> lately that
> my driver does not crash the system if I don’t have Sysinternals DebugView
> attached.
> Sometimes the same seems to be true of WinDbg – Are there extra checks
> that only
> occur when something is listening to KdPrint() output, or if not, what
> might the reason be for this?
>
> Thanks
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

Pavel_A1 · January 23, 2012, 1:50pm

On 23-Jan-2012 07:21, James Bellinger wrote:

On my test virtual machine (Windows 7 64-bit on VirtualBox), I’ve
noticed lately that
my driver does not crash the system if I don’t have Sysinternals
DebugView attached.
Sometimes the same seems to be true of WinDbg – Are there extra checks
that only
occur when something is listening to KdPrint() output, or if not, what
might the reason be for this?

Thanks

James

These tools obviously have effect on the timing and concurrency, in your
code and rest of the system.
– pa

James_Bellinger · January 23, 2012, 2:27pm

On 1/23/2012 12:30 AM, Thomas F. Divine wrote:

It there are crashes with WinDbg running - analyze them for heaven’s
sake!

If you are running the checked build of your driver, then you just
might have a flaw in one of your KdPrint statements. Perhaps bogus
formatting statement, etc. Flaws in your KdPrint’s wouldn’t appear if
you are running he free build of your driver.

In any case: Get crash -> Find YOUR bug. Don’t blame it on WinDbg or
DebugView.

Thomas F. Divine
http://www.pcausa.com
The main reason I ask about extra checks is that, for example, if I
attach WinDbg before
my KMDF-based device driver has loaded, I get a crash that doesn’t even
show my driver in the stack trace.
You can see that it crashes in IopLoadDriver (example at the bottom of
this message). If this doesn’t
normally happen, is it possibly an artifact of debugging a virtual
machine, etc.? The times when
the stack trace shows my code it tends to be an easy fix (not the most
complicated driver in the world),
but I keep running into this unusual sort. There is no problem if I
don’t attach WinDbg – the driver just loads.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!IopLoadDriver+5aa
fffff800`01ea8986 0fb77844 movzx edi,word ptr [rax+44h]

EXCEPTION_RECORD: fffff88001fdbf88 – (.exr 0xfffff88001fdbf88)
ExceptionAddress: fffff80001ea8986 (nt!IopLoadDriver+0x00000000000005aa)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000044
Attempt to read from address 0000000000000044

CONTEXT: fffff88001fdb6b0 – (.cxr 0xfffff88001fdb6b0)
rax=0000000000000000 rbx=0000000000000000 rcx=fffff88001fdc228
rdx=00000000c000007b rsi=0000000000000000 rdi=0000000000000000
rip=fffff80001ea8986 rsp=fffff88001fdc1c0 rbp=0000000020206f49
r8=fffff88007d8f000 r9=fffff88001fdc1a0 r10=fffff8a00193b060
r11=0000000000000000 r12=ffffffff80000718 r13=fffff98008f16fd0
r14=0000000000000000 r15=fffff88001fdc4cc
iopl=0 nv up ei ng nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
efl=00010286
nt!IopLoadDriver+0x5aa:
fffff80001ea8986 0fb77844 movzx edi,word ptr [rax+44h] ds:002b:0000000000000044=???
Resetting default scope

PROCESS_NAME: System

CURRENT_IRQL: 2

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000044

READ_ADDRESS: 0000000000000044

FOLLOWUP_IP:
nt!IopLoadDriver+5aa
fffff800`01ea8986 0fb77844 movzx edi,word ptr [rax+44h]

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LOCK_ADDRESS: fffff80001dc54c0 – (!locks fffff80001dc54c0)

Resource @ nt!PiEngineLock (0xfffff80001dc54c0) Exclusively owned
Contention Count = 6
NumberOfExclusiveWaiters = 1
Threads: fffffa8000d37040-01<*>
Threads Waiting On Exclusive Access:
fffffa8000d37680

1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0xfffff80001dc54c0
Thread Count : 1
Thread address: 0xfffffa8000d37040
Thread wait : 0x105ee5c1

LAST_CONTROL_TRANSFER: from fffff80001684420 to fffff8000181c060

STACK_TEXT:
fffff88001fdc1c0 fffff80001ef85d0 : ffffffff80000718 fffff80002221300 fffff88001fdc400 fffff88001fdc4cc :
nt!IopLoadDriver+0x5aa
fffff88001fdc490 fffff80002144319 : fffff8a00123ecf8 0000000000000001 fffff8a00123ecd8 000000000000001a :
nt!PipCallDriverAddDeviceQueryRoutine+0x47c
fffff88001fdc5a0 fffff80002144779 : fffff88001fdc800 fffff8a00123ecb0 fffff88001fdc654 fffff88001fdc7b8 :
nt!RtlpCallQueryRegistryRoutine+0x3b9
fffff88001fdc620 fffff80001ef7c23 : fffff98040000000 ffffffff80000740 fffff88001fdc800 fffff88001fdc7b8 :
nt!RtlQueryRegistryValues+0x3c9
fffff88001fdc720 fffff80001ef9b5c : fffffa8005a0ebd0 fffff88001fdcbc0 fffffa8005a5d010 0000000000000000 :
nt!PipCallDriverAddDevice+0x57b
fffff88001fdc8f0 fffff80001efa72a : fffffa8005a5d010 fffffa8005a29530 fffff88001fdcbc0 fffff80000000002 :
nt!PipProcessDevNodeTree+0x208
fffff88001fdcb80 fffff8000166f34c : fffffa8005a29530 0000000000000000 0000000000000000 fffffa8000d37148 :
nt!PiProcessReenumeration+0xc2
fffff88001fdcbe0 fffff800017f87c6 : 0000000000000000 fffff8000166ef34 fffff80001c90bf8 fffffa8000d37040 :
nt!PnpDeviceActionWorker+0x418
fffff88001fdcc80 fffff80002125a3d : 0000000000000001 fffffa8000d37040 0000000000000080 0000000000000000 :
nt!ExpWorkerThread+0x156
fffff88001fdcd10 fffff8000181ba26 : fffff800017f8670 0000000000000001 fffff880009b1180 0000000000000000 :
nt!PspSystemThreadStartup+0x1a9
fffff88001fdcd80 0000000000000000 : fffff88001fdd000 fffff88001fd7000 fffff88001fdb150 0000000000000000 :
nt!KxStartSystemThread+0x16

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!IopLoadDriver+5aa

Thomas_Divine · January 23, 2012, 2:54pm

Well, that one does seem unusual.

However, it’s still tough to exclude something in your driver as at least
influencing the behavior.

IOW: You could state your issue another way: “WinDbg and DebugView both work
OK unless I load my driver”.

I certainly am not smart enough to identify the cause of this problem.
Possibilities include some garbage in the INF file or possibly in the
registry since that sort of activity seems to be going on according to the
trace.

Hopefully you are using the WDK BUILD tools and not some other toolset to
build the driver.

Good luck!

Thomas F. Divine
http://www.pcausa.com

From: “James Bellinger”
Sent: Monday, January 23, 2012 2:26 PM
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] WinDbg/DebugView extra crashes?

> On 1/23/2012 12:30 AM, Thomas F. Divine wrote:
>> It there are crashes with WinDbg running - analyze them for heaven’s
>> sake!
>>
>> If you are running the checked build of your driver, then you just might
>> have a flaw in one of your KdPrint statements. Perhaps bogus formatting
>> statement, etc. Flaws in your KdPrint’s wouldn’t appear if you are
>> running he free build of your driver.
>>
>> In any case: Get crash -> Find YOUR bug. Don’t blame it on WinDbg or
>> DebugView.
>>
>> Thomas F. Divine
>> http://www.pcausa.com
> The main reason I ask about extra checks is that, for example, if I attach
> WinDbg before
> my KMDF-based device driver has loaded, I get a crash that doesn’t even
> show my driver in the stack trace.
> You can see that it crashes in IopLoadDriver (example at the bottom of
> this message). If this doesn’t
> normally happen, is it possibly an artifact of debugging a virtual
> machine, etc.? The times when
> the stack trace shows my code it tends to be an easy fix (not the most
> complicated driver in the world),
> but I keep running into this unusual sort. There is no problem if I don’t
> attach WinDbg – the driver just loads.
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
> referenced memory at 0x%08lx. The memory could not be %s.
>
> FAULTING_IP:
> nt!IopLoadDriver+5aa
> fffff80001ea8986 0fb77844 movzx edi,word ptr [rax+44h] > > EXCEPTION_RECORD: fffff88001fdbf88 -- (.exr 0xfffff88001fdbf88) > ExceptionAddress: fffff80001ea8986 (nt!IopLoadDriver+0x00000000000005aa) > ExceptionCode: c0000005 (Access violation) > ExceptionFlags: 00000000 > NumberParameters: 2 > Parameter[0]: 0000000000000000 > Parameter[1]: 0000000000000044 > Attempt to read from address 0000000000000044 > > CONTEXT: fffff88001fdb6b0 -- (.cxr 0xfffff88001fdb6b0) > rax=0000000000000000 rbx=0000000000000000 rcx=fffff88001fdc228 > rdx=00000000c000007b rsi=0000000000000000 rdi=0000000000000000 > rip=fffff80001ea8986 rsp=fffff88001fdc1c0 rbp=0000000020206f49 > r8=fffff88007d8f000 r9=fffff88001fdc1a0 r10=fffff8a00193b060 > r11=0000000000000000 r12=ffffffff80000718 r13=fffff98008f16fd0 > r14=0000000000000000 r15=fffff88001fdc4cc > iopl=0 nv up ei ng nz na po nc > cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b > efl=00010286 > nt!IopLoadDriver+0x5aa: > fffff80001ea8986 0fb77844 movzx edi,word ptr [rax+44h]
> ds:002b:0000000000000044=???? > Resetting default scope > > PROCESS_NAME: System > > CURRENT_IRQL: 2 > > ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced > memory at 0x%08lx. The memory could not be %s. > > EXCEPTION_PARAMETER1: 0000000000000000 > > EXCEPTION_PARAMETER2: 0000000000000044 > > READ_ADDRESS: 0000000000000044 > > FOLLOWUP_IP: > nt!IopLoadDriver+5aa > fffff80001ea8986 0fb77844 movzx edi,word ptr [rax+44h]
>
> BUGCHECK_STR: 0x7E
>
> DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
>
> LOCK_ADDRESS: fffff80001dc54c0 – (!locks fffff80001dc54c0)
>
> Resource @ nt!PiEngineLock (0xfffff80001dc54c0) Exclusively owned
> Contention Count = 6
> NumberOfExclusiveWaiters = 1
> Threads: fffffa8000d37040-01<*>
> Threads Waiting On Exclusive Access:
> fffffa8000d37680
>
> 1 total locks, 1 locks currently held
>
> PNP_TRIAGE:
> Lock address : 0xfffff80001dc54c0
> Thread Count : 1
> Thread address: 0xfffffa8000d37040
> Thread wait : 0x105ee5c1
>
> LAST_CONTROL_TRANSFER: from fffff80001684420 to fffff8000181c060
>
> STACK_TEXT:
> fffff88001fdc1c0 fffff80001ef85d0 : ffffffff80000718 fffff80002221300
> fffff88001fdc400 fffff88001fdc4cc : nt!IopLoadDriver+0x5aa
> fffff88001fdc490 fffff80002144319 : fffff8a00123ecf8 0000000000000001
> fffff8a00123ecd8 000000000000001a :
> nt!PipCallDriverAddDeviceQueryRoutine+0x47c
> fffff88001fdc5a0 fffff80002144779 : fffff88001fdc800 fffff8a00123ecb0
> fffff88001fdc654 fffff88001fdc7b8 :
> nt!RtlpCallQueryRegistryRoutine+0x3b9
> fffff88001fdc620 fffff80001ef7c23 : fffff98040000000 ffffffff80000740
> fffff88001fdc800 fffff88001fdc7b8 : nt!RtlQueryRegistryValues+0x3c9
> fffff88001fdc720 fffff80001ef9b5c : fffffa8005a0ebd0 fffff88001fdcbc0
> fffffa8005a5d010 0000000000000000 : nt!PipCallDriverAddDevice+0x57b
> fffff88001fdc8f0 fffff80001efa72a : fffffa8005a5d010 fffffa8005a29530
> fffff88001fdcbc0 fffff80000000002 : nt!PipProcessDevNodeTree+0x208
> fffff88001fdcb80 fffff8000166f34c : fffffa8005a29530 0000000000000000
> 0000000000000000 fffffa8000d37148 : nt!PiProcessReenumeration+0xc2
> fffff88001fdcbe0 fffff800017f87c6 : 0000000000000000 fffff8000166ef34
> fffff80001c90bf8 fffffa8000d37040 : nt!PnpDeviceActionWorker+0x418
> fffff88001fdcc80 fffff80002125a3d : 0000000000000001 fffffa8000d37040
> 0000000000000080 0000000000000000 : nt!ExpWorkerThread+0x156
> fffff88001fdcd10 fffff8000181ba26 : fffff800017f8670 0000000000000001
> fffff880009b1180 0000000000000000 : nt!PspSystemThreadStartup+0x1a9
> fffff88001fdcd80 0000000000000000 : fffff88001fdd000 fffff88001fd7000
> fffff88001fdb150 0000000000000000 : nt!KxStartSystemThread+0x16
>
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: nt!IopLoadDriver+5aa
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer