Please help in deciphering this bug check

WINDBG
1

Hi,

This question is directly related to my other post from yesterday, “How does one find the exception and exception context records”. It seems prudent to start a new thread rather than confuse the last one with a second copy/paste from windbg.

So, the previous respondent, Joe, told me to enable driver verifier and see what happens. We did this on the debugee and had the windbg going on the debugger. It’s very interesting, any machine I’ve arranged for driver verifier to run on: doesn’t boot but BSODs on boot. I’ve configured driver verifier to “look at/probe” only my driver. I’ve done this on two different machines and neither machine will cleanly boot with this configured.

Anyway, with the debugee configured thusly, I was presented this bugcheck in windbg. Because the other machine I had driver verifier running on *didn’t* get this same bug check, I rebooted the debugee to see what would happen. The debugee did get the same error as you see below.

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7E, {c0000005, 83625092, 885978fc, 885974e0}

Probably caused by : ntkrpamp.exe ( nt!IovUtilMarkDeviceObject+9 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
8368d7b8 cc int 3
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 83625092, The address that the exception occurred at
Arg3: 885978fc, Exception Record Address
Arg4: 885974e0, Context Record Address

Debugging Details:

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

FAULTING_IP:
nt!IovUtilMarkDeviceObject+9
83625092 8b80b0000000 mov eax,dword ptr [eax+0B0h]

EXCEPTION_RECORD: 885978fc – (.exr 0xffffffff885978fc)
ExceptionAddress: 83625092 (nt!IovUtilMarkDeviceObject+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000000b0
Attempt to read from address 000000b0

CONTEXT: 885974e0 – (.cxr 0xffffffff885974e0)
eax=00000000 ebx=96005808 ecx=00000002 edx=960083f8 esi=96005808 edi=00000000
eip=83625092 esp=885979c4 ebp=885979c8 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!IovUtilMarkDeviceObject+0x9:
83625092 8b80b0000000 mov eax,dword ptr [eax+0B0h] ds:0023:000000b0=???
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: 00000000

EXCEPTION_PARAMETER2: 000000b0

READ_ADDRESS: 000000b0

FOLLOWUP_IP:
nt!IovUtilMarkDeviceObject+9
83625092 8b80b0000000 mov eax,dword ptr [eax+0B0h]

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LOCK_ADDRESS: 83779be0 – (!locks 83779be0)

Resource @ nt!PiEngineLock (0x83779be0) Exclusively owned
Contention Count = 2
NumberOfExclusiveWaiters = 1
Threads: 857f34c0-01<*>
Threads Waiting On Exclusive Access:
857f3d48

1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0x83779be0
Thread Count : 1
Thread address: 0x857f34c0
Thread wait : 0x758

LAST_CONTROL_TRANSFER: from 836f1d5f to 8368d7b8

STACK_TEXT:
885979c0 83625080 88597a98 837d09f5 9a5a8ee8 nt!IovUtilMarkDeviceObject+0x9
885979c8 837d09f5 9a5a8ee8 00000000 96005808 nt!IovUtilMarkStack+0x52
88597a98 837cfedc 96005808 88597cc8 00000000 nt!PipCallDriverAddDevice+0x60a
88597c94 8379be5c 86504aa8 90a8c0c0 88597cc8 nt!PipProcessDevNodeTree+0x15d
88597cd4 83627d09 90a8c0c0 83777b00 857f34c0 nt!PiProcessStartSystemDevices+0x6d
88597d00 8369014b 00000000 00000000 857f34c0 nt!PnpDeviceActionWorker+0x241
88597d50 8381c13d 00000001 e56286f3 00000000 nt!ExpWorkerThread+0x10d
88597d90 836c3559 8369003e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!IovUtilMarkDeviceObject+9

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 521e9cb6

STACK_COMMAND: .cxr 0xffffffff885974e0 ; kb

FAILURE_BUCKET_ID: 0x7E_VRF_nt!IovUtilMarkDeviceObject+9

BUCKET_ID: 0x7E_VRF_nt!IovUtilMarkDeviceObject+9

Followup: MachineOwner

My original question from yesterday was how to find the exception record and context record. This appears to be something that is now provided for when one clicks on “!analyze -v”. However, I do need some help in deciphering what more is present.

Thanks,
Andy

2

> Hi,

This question is directly related to my other post from yesterday, “How
does one find the exception and exception context records”. It seems
prudent to start a new thread rather than confuse the last one with a
second copy/paste from windbg.

So, the previous respondent, Joe, told me to enable driver verifier and
see what happens. We did this on the debugee and had the windbg going on
the debugger. It’s very interesting, any machine I’ve arranged for driver
verifier to run on: doesn’t boot but BSODs on boot. I’ve configured
driver verifier to “look at/probe” only my driver. I’ve done this on two
different machines and neither machine will cleanly boot with this
configured.

Anyway, with the debugee configured thusly, I was presented this bugcheck
in windbg. Because the other machine I had driver verifier running on
*didn’t* get this same bug check, I rebooted the debugee to see what would
happen. The debugee did get the same error as you see below.

*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7E, {c0000005, 83625092, 885978fc, 885974e0}

Probably caused by : ntkrpamp.exe ( nt!IovUtilMarkDeviceObject+9 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
8368d7b8 cc int 3
2: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled

“Charley Five” (intermediate zeroes are silent) means access denied, and
this is almost always caused by accessing an illegal address. Keep
reading…

Arg2: 83625092, The address that the exception occurred at
Arg3: 885978fc, Exception Record Address
Arg4: 885974e0, Context Record Address

Debugging Details:

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

FAULTING_IP:
nt!IovUtilMarkDeviceObject+9
83625092 8b80b0000000 mov eax,dword ptr [eax+0B0h]

At this point, go down a couple lines and look at what is in eax. It is
zero. This means you have attempted to dereference a NULL pointer.

EXCEPTION_RECORD: 885978fc – (.exr 0xffffffff885978fc)
ExceptionAddress: 83625092 (nt!IovUtilMarkDeviceObject+0x00000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000000b0

This is the address you tried to access, which is definitely illegal

Attempt to read from address 000000b0

CONTEXT: 885974e0 – (.cxr 0xffffffff885974e0)
eax=00000000 ebx=96005808 ecx=00000002 edx=960083f8 esi=96005808
edi=00000000
eip=83625092 esp=885979c4 ebp=885979c8 iopl=0 nv up ei pl nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010202
nt!IovUtilMarkDeviceObject+0x9:
83625092 8b80b0000000 mov eax,dword ptr [eax+0B0h]
ds:0023:000000b0=???
Resetting default scope

PROCESS_NAME: System

CURRENT_IRQL: 2

It happened at DISPATCH_LEVEL (2). but that is irrelevant. At
PASSIVE_LEVEL, it is still an illegal memory access.

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

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 000000b0

READ_ADDRESS: 000000b0

FOLLOWUP_IP:
nt!IovUtilMarkDeviceObject+9
83625092 8b80b0000000 mov eax,dword ptr [eax+0B0h]

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LOCK_ADDRESS: 83779be0 – (!locks 83779be0)

Resource @ nt!PiEngineLock (0x83779be0) Exclusively owned
Contention Count = 2
NumberOfExclusiveWaiters = 1
Threads: 857f34c0-01<*>
Threads Waiting On Exclusive Access:
857f3d48

1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0x83779be0
Thread Count : 1
Thread address: 0x857f34c0
Thread wait : 0x758

LAST_CONTROL_TRANSFER: from 836f1d5f to 8368d7b8

STACK_TEXT:
885979c0 83625080 88597a98 837d09f5 9a5a8ee8
nt!IovUtilMarkDeviceObject+0x9
885979c8 837d09f5 9a5a8ee8 00000000 96005808 nt!IovUtilMarkStack+0x52
88597a98 837cfedc 96005808 88597cc8 00000000
nt!PipCallDriverAddDevice+0x60a
88597c94 8379be5c 86504aa8 90a8c0c0 88597cc8
nt!PipProcessDevNodeTree+0x15d
88597cd4 83627d09 90a8c0c0 83777b00 857f34c0
nt!PiProcessStartSystemDevices+0x6d
88597d00 8369014b 00000000 00000000 857f34c0
nt!PnpDeviceActionWorker+0x241
88597d50 8381c13d 00000001 e56286f3 00000000 nt!ExpWorkerThread+0x10d
88597d90 836c3559 8369003e 00000001 00000000

You would have to see what the thread is doing to invoke this function
with a NULL pointer.

nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!IovUtilMarkDeviceObject+9

I suspect a NULL pointer to a device object, but have no idea how you
managed that.

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 521e9cb6

STACK_COMMAND: .cxr 0xffffffff885974e0 ; kb

FAILURE_BUCKET_ID: 0x7E_VRF_nt!IovUtilMarkDeviceObject+9

BUCKET_ID: 0x7E_VRF_nt!IovUtilMarkDeviceObject+9

Followup: MachineOwner

My original question from yesterday was how to find the exception record
and context record. This appears to be something that is now provided for
when one clicks on “!analyze -v”. However, I do need some help in
deciphering what more is present.

You have done something, whether deliberate (carefully passing a NULL
pointer where one is not legal) or accidentally (overwriting some key
structure by using a bad pointer or an out-of-bounds array index). You
will have to analyze your code to see what you might have done.

Can’t really tell more that this without seeing the code in your worker
thread.

Thanks,
Andy

WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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

3

Can you also include the output of !verifier ?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@micron.com
Sent: Tuesday, February 25, 2014 12:00 PM
To: Kernel Debugging Interest List
Subject: [windbg] Please help in deciphering this bug check

Hi,

This question is directly related to my other post from yesterday, “How does one find the exception and exception context records”. It seems prudent to start a new thread rather than confuse the last one with a second copy/paste from windbg.

So, the previous respondent, Joe, told me to enable driver verifier and see what happens. We did this on the debugee and had the windbg going on the debugger. It’s very interesting, any machine I’ve arranged for driver verifier to run on: doesn’t boot but BSODs on boot. I’ve configured driver verifier to “look at/probe” only my driver. I’ve done this on two different machines and neither machine will cleanly boot with this configured.

Anyway, with the debugee configured thusly, I was presented this bugcheck in windbg. Because the other machine I had driver verifier running on *didn’t* get this same bug check, I rebooted the debugee to see what would happen. The debugee did get the same error as you see below.

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7E, {c0000005, 83625092, 885978fc, 885974e0}

Probably caused by : ntkrpamp.exe ( nt!IovUtilMarkDeviceObject+9 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
8368d7b8 cc int 3
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) 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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 83625092, The address that the exception occurred at
Arg3: 885978fc, Exception Record Address
Arg4: 885974e0, Context Record Address

4

It may surprise you that this tells us a lot about what is happening.

When DV is running, it injects itself into the path between your driver
and the actual I/O system. This changes the stack patterns. So the
behavior changes. For example, the pointer that was once NULL may now be
non-NULL. Unknown, unpredictable, but non-NULL, and a legitimate address.
Unfortunately, special pool won’t help here, because the special pool
deals with allocations of your driver, and thus, if the pointer is a stale
pointer left over from some other driver, or a stack pointer referencing a
location elsewhere in the stack, the fetch from it will not cause an
access failure. What you get may be nonsense, but you won’t get the
access failure.

So now you have something specific to look for. What I usually suggest is
declaring all local pointer variables as

PWHATEVER nameofyourchoice = NULL;

Note that in the debug version, this will generate an extra couple
instructions, but in the release version, it will only do this
initialization if there is no other store-before-use (assuming you have
enabled optimizations) so it is great for debugging and has zero cost in
release.

It is also possible that you have an uninitialized pointer in a structure
you allocate, but it is far less likely that putting DV in will change
this in such a consistent manner. So I’d look for uninitialized pointers
as the first cut. Note if you run the analysis formerly known as PreFast,
it will catch use-before-store and also use constant propagation analysis
to detect that NULL propagates down to a place where it is illegal.

At least, that’s what I would try if faced with this problem.
joe

Can you also include the output of !verifier ?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@micron.com
Sent: Tuesday, February 25, 2014 12:00 PM
To: Kernel Debugging Interest List
Subject: [windbg] Please help in deciphering this bug check

Hi,

This question is directly related to my other post from yesterday, “How
does one find the exception and exception context records”. It seems
prudent to start a new thread rather than confuse the last one with a
second copy/paste from windbg.

So, the previous respondent, Joe, told me to enable driver verifier and
see what happens. We did this on the debugee and had the windbg going on
the debugger. It’s very interesting, any machine I’ve arranged for driver
verifier to run on: doesn’t boot but BSODs on boot. I’ve configured
driver verifier to “look at/probe” only my driver. I’ve done this on two
different machines and neither machine will cleanly boot with this
configured.

Anyway, with the debugee configured thusly, I was presented this bugcheck
in windbg. Because the other machine I had driver verifier running on
*didn’t* get this same bug check, I rebooted the debugee to see what would
happen. The debugee did get the same error as you see below.

*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7E, {c0000005, 83625092, 885978fc, 885974e0}

Probably caused by : ntkrpamp.exe ( nt!IovUtilMarkDeviceObject+9 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
8368d7b8 cc int 3
2: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) 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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 83625092, The address that the exception occurred at
Arg3: 885978fc, Exception Record Address
Arg4: 885974e0, Context Record Address

WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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

5

Thanks for the help with this. I’ve been quite busy lately or I’d have mentioned something sooner. I would like to know how to glean something out of the DV through windbg or whatever. Whenever I setup the DV program for this particular driver, windows cannot boot. It BSODs without fail. I’m going to go through the driver code and put in the local assignments as you (Joe) has suggested but I’m not sure what more I can do. I’m still quite naive with windbg.

Thanks again.

6

> Thanks for the help with this. I’ve been quite busy lately or I’d have

mentioned something sooner. I would like to know how to glean something
out of the DV through windbg or whatever. Whenever I setup the DV program
for this particular driver, windows cannot boot. It BSODs without fail.
I’m going to go through the driver code and put in the local assignments
as you (Joe) has suggested but I’m not sure what more I can do. I’m still
quite naive with windbg.

Well, that BSOD also tells a lot. Is the device plugged in when you boot?
Is it PCI? PCIe? USB? If the device is “plugged in” (whether in USB or
the backplane) then the driver will be loaded. If you have DV set up to
use special pool, the error is being detected when the driver is loaded
(during the boot) and it actually finds the error. Errors caused by
memory usage (dangling pointers, etc.) will manifest as a BSOD. If you
can get a !analyze -v when it crashes (live) or from a dump (passive),
that will tell you something interesting.

If the device is removed, does it BSOD during boot? If not, this tells
you that DriverEntry, AddDevice, the START event, or power management, is
guilty. This narrows the field a lot; you know it isn’t in the Open,
Close, Read, Write or DeviceIoControl are not the problem, and you don’t
need to bother looking there. This has narrowed your search considerably.
The simplest massage might be to do

NTSTATUS DriverEntry(…etc…)
{
#if 0
… the code
#else
return STATUS_SUCCESS;
#endif
}

and repeat in AddDevice, Power Management, and Start as needed. Yes, the
world is not what you want, but if dropping the code out eliminates the
error, you’ve got a pretty good idea where the error is. Note this is not
absolute; dropping out code might cause some later event to either BSOD
when it would not normally have, or just cause the system to do something
that is rejected (e.g., if you comment out the DriverEntry code, you won’t
ever get to your PnP or Power handlers, so it won’t BSOD if there’s a
problem in those areas, because it won’t get there). But it is one way to
isolate the failure point. But the !analyze -v output will help you pin
the problem down more precisely.
joe

Thanks again.

WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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

7

Joe,

Yes, the device is plugged in and I believe it would be PCI. The driver is question is a custom AHCI driver for the AHCI HBA. What exactly do you mean by having DV setup to use “special pool”? I didn’t see an option for this when I went through the steps of setting up the DV.

Andy

8

Another question is, now that I have windbg setup for debugging the other system’s kernel and drivers, what do I do after the exception is caught and the BSOD happens? I have tried this once already but the !analyze -v only shows what I’ve already copy/pasted at the beginning of this thread. How do I dig deeper?

9

> Another question is, now that I have windbg setup for debugging the other

system’s kernel and drivers, what do I do after the exception is caught
and the BSOD happens? I have tried this once already but the !analyze -v
only shows what I’ve already copy/pasted at the beginning of this thread.
How do I dig deeper?

Well, what you posted at the beginning did not have DV working or crash on
bootup. That output would now be more informative. So that’s the first
“deeper” you should study.
joe

WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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

10

> Joe,

Yes, the device is plugged in and I believe it would be PCI. The driver
is question is a custom AHCI driver for the AHCI HBA. What exactly do you
mean by having DV setup to use “special pool”? I didn’t see an option for
this when I went through the steps of setting up the DV.

Andy

Run “verifier”
Check "Create Custom Settings (for code developers)
Select “Select individual settings from a full list”

The first option on the list is “special pool”
joe

WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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

11

First of all, I’ve changed my settings for this group so that I get mail. Hopefully, that will help me preserve context of my questions better.

Joe, I’ve followed your advice for verifier settings. Interestingly, the “Special Pool” watch didn’t cause the BSOD. I systematically turned on one more at a time until I got the BSOD. The BSOD happens with the following turned on:

* Special Pool
* Pool Tracking
* Force IRQL Tracking
* I/O Verification

As suggested by the order, it was when I turned on I/O Verification that I got the BSOD. I assure this time that verifier is running as windbg shows a line stating that Driver Verifier is enabled for my driver.

Here is the copy/paste for the !analyze -v with these enabled:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7E, {ffffffffc0000005, fffff80003963399, fffff8800379a528, fffff88003799d80}

Probably caused by : ntkrnlmp.exe ( nt!IovUtilMarkDeviceObject+9 )

Followup: MachineOwner

nt!DbgBreakPointWithStatus:
fffff800`038d19f0 cc int 3
7: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80003963399, The address that the exception occurred at
Arg3: fffff8800379a528, Exception Record Address
Arg4: fffff88003799d80, Context Record Address

Debugging Details:

OVERLAPPED_MODULE: Address regions for ‘umbus’ and ‘1394ohci.sys’ overlap

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

FAULTING_IP:
nt!IovUtilMarkDeviceObject+9
fffff800`03963399 488b8938010000 mov rcx,qword ptr [rcx+138h]

EXCEPTION_RECORD: fffff8800379a528 – (.exr 0xfffff8800379a528)
ExceptionAddress: fffff80003963399 (nt!IovUtilMarkDeviceObject+0x0000000000000009)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000138
Attempt to read from address 0000000000000138

CONTEXT: fffff88003799d80 – (.cxr 0xfffff88003799d80)
rax=0000000000000000 rbx=fffffa8008c3f7d0 rcx=0000000000000000
rdx=0000000000000002 rsi=0000000000000000 rdi=0000000000000005
rip=fffff80003963399 rsp=fffff8800379a768 rbp=fffffa8008c2ebf0
r8=0000000000000000 r9=fffffa8008c2ebf0 r10=fffffa8008c2ebf0
r11=fffff8800379a438 r12=fffffa8008c278b0 r13=0000000000000005
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010202
nt!IovUtilMarkDeviceObject+0x9:
fffff80003963399 488b8938010000 mov rcx,qword ptr [rcx+138h] ds:002b:0000000000000138=???
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: 0000000000000138

READ_ADDRESS: 0000000000000138

FOLLOWUP_IP:
nt!IovUtilMarkDeviceObject+9
fffff800`03963399 488b8938010000 mov rcx,qword ptr [rcx+138h]

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LOCK_ADDRESS: fffff80003addbe0 – (!locks fffff80003addbe0)

Resource @ nt!PiEngineLock (0xfffff80003addbe0) Exclusively owned
Contention Count = 2
NumberOfExclusiveWaiters = 1
Threads: fffffa8005530040-01<*>
Threads Waiting On Exclusive Access:
fffffa8005530660

1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0xfffff80003addbe0
Thread Count : 1
Thread address: 0xfffffa8005530040
Thread wait : 0x386

LAST_CONTROL_TRANSFER: from fffff800039caa12 to fffff800038d19f0

STACK_TEXT:
fffff8800379a768 fffff80003991a57 : 0000000000000000 0000000000000000 0000000000000005 0000000000000002 : nt!IovUtilMarkDeviceObject+0x9
fffff8800379a770 fffff80003cc79fd : fffffa8008c2ebf0 0000000000000000 fffff8a000aec0a0 fffff8a000aec0a0 : nt!IovUtilMarkStack+0x67
fffff8800379a7a0 fffff80003cc8ed2 : fffffa8008c3f7d0 fffffa8008c3f7d0 0000000000000000 fffffa8008c278b0 : nt!PipCallDriverAddDevice+0x71d
fffff8800379a950 fffff80003cc936c : fffff80003adb560 0000000000000000 0000000000000001 fffff80003b44e08 : nt!PipProcessDevNodeTree+0x2b2
fffff8800379abc0 fffff800039dc802 : 0000000100000003 fffff80003a7f2d8 0000000000000001 0000000000000000 : nt!PiProcessStartSystemDevices+0x7c
fffff8800379ac10 fffff800038e3261 : fffff800039dc500 fffff8a000839401 fffff80003a7f200 edffedff0000055a : nt!PnpDeviceActionWorker+0x302
fffff8800379acb0 fffff80003b762ea : 2e132e13f08df08d fffffa8005530040 0000000000000080 fffffa80054a3b30 : nt!ExpWorkerThread+0x111
fffff8800379ad40 fffff800038ca8e6 : fffff8800356a180 fffffa8005530040 fffff880035750c0 1a141a14d901d901 : nt!PspSystemThreadStartup+0x5a
fffff8800379ad80 0000000000000000 : fffff8800379b000 fffff88003795000 fffff88003799b10 0000000000000000 : nt!KiStartSystemThread+0x16

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!IovUtilMarkDeviceObject+9

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 521ea035

STACK_COMMAND: .cxr 0xfffff88003799d80 ; kb

FAILURE_BUCKET_ID: X64_0x7E_VRF_nt!IovUtilMarkDeviceObject+9

BUCKET_ID: X64_0x7E_VRF_nt!IovUtilMarkDeviceObject+9

Followup: MachineOwner

So, what more does this show?

12

I’ve spent some time digging into this driver of ours. In the AddDevice routine/function, I find that the call to IoAttachDeviceToDeviceStack is commented. The writeup for AddDevice on MSDN says as much (http://msdn.microsoft.com/en-us/library/windows/hardware/ff540521(v=vs.85).aspx).

Another thing, after reviewing this link (http://msdn.microsoft.com/en-us/library/windows/hardware/ff540529(v=vs.85).aspx) on MSDN for how to write and AddDevice function for a Function Driver, I’m pretty sure we’re skipping steps 3-8. I’m a little foggy on step 3 though. Step 3 says, “Store the pointer to the device’s PDO in the device extension.” There is the following line in our AddDevice function:

pDevExt = (WinIoDevExt*) DeviceObject->DeviceExtension;

However, pDevExt is a local variable to AddDevice. Is this step supposed/expected to set this to a global variable for the driver?

13

xxxxx@micron.com wrote:

I’ve spent some time digging into this driver of ours. In the AddDevice routine/function, I find that the call to IoAttachDeviceToDeviceStack is commented. The writeup for AddDevice on MSDN says as much (http://msdn.microsoft.com/en-us/library/windows/hardware/ff540521(v=vs.85).aspx).

What kind of a driver is this? A PnP driver will always call
IoAttachDeviceToDeviceStack in AddDevice (although KMDF will do it for you).

Another thing, after reviewing this link (http://msdn.microsoft.com/en-us/library/windows/hardware/ff540529(v=vs.85).aspx) on MSDN for how to write and AddDevice function for a Function Driver, I’m pretty sure we’re skipping steps 3-8.

Those are important steps, although it depends on exactly what kind of
driver you are.

I’m a little foggy on step 3 though. Step 3 says, “Store the pointer to the device’s PDO in the device extension.” There is the following line in our AddDevice function:

pDevExt = (WinIoDevExt*) DeviceObject->DeviceExtension;

However, pDevExt is a local variable to AddDevice. Is this step supposed/expected to set this to a global variable for the driver?

No. The DEVICE_OBJECT is passed to every driver function, and the
extension is stored in the DEVICE_OBJECT. So, you’ll have that line in
virtually every function you write. The whole POINT of this is to avoid
global variables, because your driver can be handling multiple devices,
each of which has its own extension.

So, they’re saying your AddDevice would have
pDevExt->PDO = PhysicalDeviceObject;

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

14

>

What kind of a driver is this? A PnP driver will always call
IoAttachDeviceToDeviceStack in AddDevice (although KMDF will do it for
you).

I’m so na?ve in driver development, I’m not sure how to tell. I know that this driver is built with the 8.1 DDK, but that probably doesn’t help much. If you can tell me how to discern this, the rest may answer themselves (or at least be closer).

Andy

15

Andy Falanga (afalanga) wrote:

> What kind of a driver is this? A PnP driver will always call
> IoAttachDeviceToDeviceStack in AddDevice (although KMDF will do it for
> you).
I’m so naïve in driver development, I’m not sure how to tell. I know that this driver is built with the 8.1 DDK, but that probably doesn’t help much. If you can tell me how to discern this, the rest may answer themselves (or at least be closer).

I went back in the thread where you said it was an AHCI driver. I’m not
a disk guy; I don’t know if there are special rules in the disk stack,
so I shouldn’t comment any more.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.