How does one find the exception and exception context records

WINDBG
1

Hi,

I’m isolating an issue on some systems which routinely cause BSODs. The issue seems to point to a driver that my team maintains. Although I didn’t write the driver, I am transitioning to driver maintenance and writing. I’m referencing an old book, “The Windows 2000 Device Driver Book.” While definitely dated, it did at least put me onto the right path.

The driver is compiled for Windows 7 32 and 64 bit. Most recently, I connected windbg to the problem PC via firewire and was debugging in real time. None of the memory files from previous dumps ever show our driver as the culprit but instead show ntkrnlmp (usually) and occasionally werfault.exe. I don’t buy that the kernel has problems.

A colleague showed me from the book that I’m very interested in the exception record and the exception context record. The book shows a function at the top of the stack named PspUnhandledExceptionInSystemThread(). This function doesn’t appear anywhere in my call stack. Since I’m using Windows 7, I must conclude this means either I didn’t reach it or it isn’t applicable to Win 7. I expect the latter is the case.

However, this function has, as it’s arguments, a pointer to a structure which has the exception record. I’m figuring that my stack dump also has this I just don’t know what I’m looking for.

My build of windbg: 6.12.0002.633
My stack dump:
nt!RtlpBreakWithStatusInstruction
nt!KiBugCheckDebugBreak+0x1c
nt!KeBugCheck2+0xa7f
nt!KiTrap0E+0x1b3
WARNING: Stack unwind information not available. Following frames may be wrong.
igdkmd32!hybDriverEntry+0x14f169
igdkmd32!hybDriverEntry+0x134e9b
igdkmd32!hybDriverEntry+0x137d98
igdkmd32!hybDriverEntry+0x218a2
igdkmd32!hybDriverEntry+0x21c51
crashdmp!InvokeSecondaryDumpCallbacks+0x129
crashdmp!DumpWrite+0x12b
crashdmp!CrashdmpWrite+0x53
nt!IoWriteCrashDump+0x26c
nt!KeBugCheck2+0x9fb
nt!KiTrap0E+0x1b3
nt!MiAgeWorkingSet+0x1f0
nt!MiProcessWorkingSets+0x25b
nt!MmWorkingSetManager+0xa4
nt!KeBalanceSetManager+0x1af
nt!PspSystemThreadStartup+0x9e

It’s rather interesting that the call stack shows this when I had windbg setup through firewire like this. I have several crash dumps from other machines and they all stop at KeBugCheckEx.

At any rate, I’d really appreciate any help that you can give me. I’m quite new to all of this. In fact, I learned more about windbg this afternoon (a couple of hours) than I ever knew before hand.

Thanks,
Andy

2

> Hi,

I’m isolating an issue on some systems which routinely cause BSODs. The
issue seems to point to a driver that my team maintains. Although I
didn’t write the driver, I am transitioning to driver maintenance and
writing. I’m referencing an old book, “The Windows 2000 Device Driver
Book.” While definitely dated, it did at least put me onto the right
path.

The driver is compiled for Windows 7 32 and 64 bit. Most recently, I
connected windbg to the problem PC via firewire and was debugging in real
time. None of the memory files from previous dumps ever show our driver
as the culprit but instead show ntkrnlmp (usually) and occasionally
werfault.exe. I don’t buy that the kernel has problems.

A colleague showed me from the book that I’m very interested in the
exception record and the exception context record. The book shows a
function at the top of the stack named
PspUnhandledExceptionInSystemThread(). This function doesn’t appear
anywhere in my call stack. Since I’m using Windows 7, I must conclude
this means either I didn’t reach it or it isn’t applicable to Win 7. I
expect the latter is the case.

However, this function has, as it’s arguments, a pointer to a structure
which has the exception record. I’m figuring that my stack dump also has
this I just don’t know what I’m looking for.

My build of windbg: 6.12.0002.633
My stack dump:
nt!RtlpBreakWithStatusInstruction
nt!KiBugCheckDebugBreak+0x1c
nt!KeBugCheck2+0xa7f
nt!KiTrap0E+0x1b3
WARNING: Stack unwind information not available. Following frames may be
wrong.
igdkmd32!hybDriverEntry+0x14f169
igdkmd32!hybDriverEntry+0x134e9b
igdkmd32!hybDriverEntry+0x137d98
igdkmd32!hybDriverEntry+0x218a2
igdkmd32!hybDriverEntry+0x21c51
crashdmp!InvokeSecondaryDumpCallbacks+0x129
crashdmp!DumpWrite+0x12b
crashdmp!CrashdmpWrite+0x53
nt!IoWriteCrashDump+0x26c
nt!KeBugCheck2+0x9fb
nt!KiTrap0E+0x1b3
nt!MiAgeWorkingSet+0x1f0
nt!MiProcessWorkingSets+0x25b
nt!MmWorkingSetManager+0xa4
nt!KeBalanceSetManager+0x1af
nt!PspSystemThreadStartup+0x9e

It’s rather interesting that the call stack shows this when I had windbg
setup through firewire like this. I have several crash dumps from other
machines and they all stop at KeBugCheckEx.

Several things:

A stack dump when you don’t have the correct symbols loaded is dubious.
The fragment of the stack dump you show sggests data corruption, possibly
caused by improper use of pointers. Without the full !analyze -v output,
it is hard to say much more than that.

Learn how to set up windbg to use the Mi rosoft Symbol Server.

Try running Driver Verifier to see if it detects anything. If the same
problem arises without the DV reporting helpful informatiom, try running
it with Special Pool enabled.

Note that for memory damage, the component that detects the damage is an
innocent bystander and is collateral damage. Therefore, your driver may
be nowhere in the traceback. This does not make it innocent.
joe

At any rate, I’d really appreciate any help that you can give me. I’m
quite new to all of this. In fact, I learned more about windbg this
afternoon (a couple of hours) than I ever knew before hand.

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

Joe,

Thanks for your reply. As for symbols, I had windbg setup with the following for symbols:

.sympath srv*c:\cachedsymbols*Symbol information
.sympath+ c:\MyDriversSymbols

I know full well that my driver may be the issue. It seems unlikely because the driver has been in use for nearly a year and half without issues like this, but it's not off the table yet for consideration.

Thanks for the suggestion on Driver Verifier. I've not heard of that before. I'll be Googling for that and figuring out how to use it.

I don't know if it will be helpful because not every memory dump file I have is for the exact same bugcheck. However, here's the full anaylize -v from a different memory dump:

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

MEMORY_MANAGEMENT (1a)

Any other values for parameter 1 must be individually examined.

Arguments:
Arg1: 0000000000005100, The subtype of the bugcheck.
Arg2: fffff6fd40060000
Arg3: 00000000000001d2
Arg4: 000000000de986e0

Debugging Details:

BUGCHECK_STR: 0x1a_5100

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80003addba7 to fffff80003a84c40

STACK_TEXT:
fffff880033921a8 fffff80003addba7 : 000000000000001a 0000000000005100 fffff6fd40060000 00000000000001d2 : nt!KeBugCheckEx
fffff880033921b0 fffff80003bb6b5e : 00000000000001d2 fffff88003392300 fffff6fd40060000 fffffa80065e5800 : nt! ?? ::FNODOBFM::string'+0xaed7 fffff880033922c0 fffff80003aa4ab0 : 00000000001d2000 fffff80003c15580 0000000000000004 0000000000000001 : nt!MiAllocatePoolPages+0x4de fffff88003392400 fffff80003bba43e : 0000000000000000 00000000000001d2 0000000000000000 00000000001d2000 : nt!ExpAllocateBigPool+0xb0 fffff880033924f0 fffff88001424c24 : fffff88003392800 0000000000000000 fffff88003392bf0 fffff8800141f889 : nt!ExAllocatePoolWithTag+0x82e fffff880033925e0 fffff88001424d05 : fffff88003392800 fffff880033926cc fffff88003392808 fffffa8008fb8760 : Ntfs!NtfsCreateMdlAndBuffer+0xe4 fffff88003392630 fffff8800141dcb2 : fffff88003392bf0 fffffa8008fb8760 fffff88003392800 0000000000000000 : Ntfs!NtfsAllocateCompressionBuffer+0x75 fffff88003392680 fffff8800141f40b : fffff88003392bf0 fffffa8008fb8760 fffffa8006e38b80 000000001842e000 : Ntfs!NtfsPrepareSimpleBuffers+0x122 fffff88003392730 fffff8800141e63c : fffffa8008fb8760 fffffa8006e24d80 fffff88003392850 fffff8a000000000 : Ntfs!NtfsPrepareBuffers+0xcb fffff880033927b0 fffff88001427578 : fffff88003392bf0 fffffa8008fb8760 0000000000000000 0000000000000000 : Ntfs!NtfsNonCachedIo+0x1bc fffff88003392980 fffff880014227c7 : fffff88003392bf0 fffffa8008fb8760 fffffa8006e38b80 000000001842e000 : Ntfs!NtfsNonCachedUsaWrite+0x64 fffff88003392a10 fffff88001423463 : fffff88003392bf0 fffffa8008fb8760 fffff88003392d00 fffff880001d2000 : Ntfs!NtfsCommonWrite+0x2ca4 fffff88003392bc0 fffff88001202bcf : fffffa8008fb8a70 fffffa8008fb8760 fffffa800bdcf740 0000000000000000 : Ntfs!NtfsFsdWrite+0x1c3 fffff88003392e40 fffff880012016df : fffffa8006e32de0 fffffa800671cb70 fffffa8006e32d00 fffffa8008fb8760 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f fffff88003392ed0 fffff80003a69f0f : fffffa8008fb8760 fffff88003393400 fffffa800be5b140 fffff88003165180 : fltmgr!FltpDispatch+0xcf fffff88003392f30 fffff80003ac7e8b : 0000000000018400 fffff88003393400 fffffa80022f5090 0000000000000000 : nt!IoSynchronousPageWrite+0x24f fffff88003392fb0 fffff80003ac6518 : fffff8a01b349170 fffff8a01b34a000 fffffa800af7b160 fffffa800af7b160 : nt!MiFlushSectionInternal+0xb7b fffff880033931f0 fffff80003ac58a9 : fffffa8006e3a840 0000000000000000 00000000001d2000 0000000000000000 : nt!MmFlushSection+0x1f4 fffff880033932b0 fffff880014f7025 : fffffa8006e3a840 0000000000000000 fffffa8000000000 00000002001d2000 : nt!CcFlushCache+0x5e9 fffff880033933b0 fffff880014d1fa2 : fffff88003393970 0000000000000000 fffff80003c2b200 fffff88003393501 : Ntfs!NtfsFlushLsnStreams+0x295 fffff88003393450 fffff880014d4977 : fffff88003393970 fffffa8006eeb180 fffff88003393900 fffff88001427400 : Ntfs!NtfsCheckpointVolume+0x13e6 fffff88003393850 fffff880014d3317 : fffff88003393970 fffffa8006eeb180 fffffa8006eeb188 fffff8800141a020 : Ntfs!NtfsCheckpointAllVolumesWorker+0x4b fffff880033938a0 fffff880014d5428 : fffff88003393970 0000000000000000 fffff880014d492c fffff88003393b78 : Ntfs!NtfsForEachVcb+0x167 fffff88003393940 fffff80003a8dca9 : fffffa800675c700 fffff80003d7ec00 fffff80003c8c800 0000000000000002 : Ntfs!NtfsCheckpointAllVolumes+0xb8 fffff88003393b70 fffff80003d2534a : 7367358c640fbc95 fffffa800676ab50 0000000000000080 fffffa80066f8040 : nt!ExpWorkerThread+0x111 fffff88003393c00 fffff80003a75946 : fffff88003165180 fffffa800676ab50 fffff8800316ffc0 0000000000000000 : nt!PspSystemThreadStartup+0x5a fffff88003393c40 0000000000000000 : fffff88003394000 fffff8800338e000 fffff88003392500 00000000`00000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::string'+aed7 fffff80003addba7 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+aed7

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 50e79935

FAILURE_BUCKET_ID: X64_0x1a_5100_nt!??::FNODOBFM::string+aed7

BUCKET_ID: X64_0x1a_5100_nt!??::FNODOBFM::string+aed7

Followup: MachineOwner

Andy