How to debug BugCheck 19

OSR_Community_User · April 20, 2007, 7:51am

Dear friends.

I have a bugcheck in my driver.

BugCheck 19, {20, 85ed4a78, 85ed4c80, a410001}

Ourput from !analyze -v

kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

BAD_POOL_HEADER (19)

The pool is already corrupt at the time of the current request.

This may or may not be due to the caller.

The internal pool links must be walked to figure out a possible cause of

the problem, and then special pool applied to the suspect tags or the driver

verifier to a suspect driver.

Arguments:

Arg1: 00000020, a pool block header size is corrupt.

Arg2: 85ed4a78, The pool entry we were looking for within the page.

Arg3: 85ed4c80, The next pool entry.

Arg4: 0a410001, (reserved)

Debugging Details:

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: 85ed4a78 Nonpaged pool

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: pru_tabic.exe

LAST_CONTROL_TRANSFER: from 8054be41 to 805339ae

STACK_TEXT:

ee307ab4 8054be41 00000019 00000020 85ed4a78 nt!KeBugCheckEx+0x1b

ee307b04 80514cb1 85ed4a80 00000000 8568b1d0 nt!ExFreePoolWithTag+0x2be

ee307b20 806f11f6 85ed4a80 ee307b54 f6fe7386 nt!MmFreeContiguousMemory+0x121

ee307b2c f6fe7386 85f791c8 00000200 05ed4a80 hal!HalFreeCommonBuffer+0xe

ee307b54 f6fcd896 85e50a80 804e59ec 8568b210 tabic!LiberaCommonBuffersPCI+0x76 [c:\icfnt\driversnt\tabic\dma.c @ 2644]

ee307ba4 f6fc11f2 85e50a80 8568b1d0 8568b264 tabic!TabicIoctlStartDMAEx+0x2d6 [c:\icfnt\driversnt\tabic\ioctl.c @ 2405]

ee307c34 804e3d77 85e509c8 8568b1d0 806ef2d0 tabic!TabicDispatch+0xc02 [c:\icfnt\driversnt\tabic\dispatch.c @ 542]

ee307c44 8056a9ab 8568b264 85e922e8 8568b1d0 nt!IopfCallDriver+0x31

ee307c58 8057d9f7 85e509c8 8568b1d0 85e922e8 nt!IopSynchronousServiceTail+0x60

ee307d00 8057fbfa 000007d4 00000000 00000000 nt!IopXxxControlFile+0x611

ee307d34 804df06b 000007d4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a

ee307d34 7c91eb94 000007d4 00000000 00000000 nt!KiFastCallEntry+0xf8

0012fac0 7c91d8ef 7c801671 000007d4 00000000 ntdll!KiFastSystemCallRet

0012fac4 7c801671 000007d4 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc

0012fb24 00401338 000007d4 9c40a16c 0012fe6c kernel32!DeviceIoControl+0xdd

WARNING: Stack unwind information not available. Following frames may be wrong.

0012fba8 004036fd 000007d4 9c40a16c 0012fe6c pru_tabic+0x1338

0012ff80 004077dc 00000002 00392860 003928a8 pru_tabic+0x36fd

0012ffc0 7c816d4f 0000001a 00000000 7ffde000 pru_tabic+0x77dc

0012fff0 00000000 004076e0 00000000 78746341 kernel32!BaseProcessStart+0x23

STACK_COMMAND: kb

FOLLOWUP_IP:

tabic!LiberaCommonBuffersPCI+76 [c:\icfnt\driversnt\tabic\dma.c @ 2644]

f6fe7386 8b4508 mov eax,dword ptr [ebp+8]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: tabic!LiberaCommonBuffersPCI+76

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: tabic

IMAGE_NAME: tabic.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 46287837

FAILURE_BUCKET_ID: 0x19_20_tabic!LiberaCommonBuffersPCI+76

BUCKET_ID: 0x19_20_tabic!LiberaCommonBuffersPCI+76

Followup: MachineOwner

In WinDbg I can dump the entire memory range at 85ED4A80 (virtual address of the common buffer passed to FreeCommonBuffer) everything seems OK (the common buffer is 512 bytes long and is filled with 0x55). As suggested, I have enabled driver verifier for my driver (tabic.sys). The problem is that with driver verifier enabled the system does not crash.

Is there any way to search fro more information in the dump?

System is Windows XP SP2, WinDbg 6.6.0007.5, DDK 3790.1830

Best regards.

Maxim_S_Shatskih · April 20, 2007, 8:22am

You have overwrote some memory via the stray pointer and spoiled the pool
block headers.

Verifier’s Special Pool feature helps a lot.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Julián Rodríguez” wrote in message
news:xxxxx@ntdev…
Dear friends.

I have a bugcheck in my driver.

BugCheck 19, {20, 85ed4a78, 85ed4c80, a410001}

Ourput from !analyze -v

kd> !analyze -v

Bugcheck Analysis

BAD_POOL_HEADER (19)

The pool is already corrupt at the time of the current request.

This may or may not be due to the caller.

The internal pool links must be walked to figure out a possible cause of

the problem, and then special pool applied to the suspect tags or the driver

verifier to a suspect driver.

Arguments:

Arg1: 00000020, a pool block header size is corrupt.

Arg2: 85ed4a78, The pool entry we were looking for within the page.

Arg3: 85ed4c80, The next pool entry.

Arg4: 0a410001, (reserved)

Debugging Details:

------------------

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: 85ed4a78 Nonpaged pool

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: pru_tabic.exe

LAST_CONTROL_TRANSFER: from 8054be41 to 805339ae

STACK_TEXT:

ee307ab4 8054be41 00000019 00000020 85ed4a78 nt!KeBugCheckEx+0x1b

ee307b04 80514cb1 85ed4a80 00000000 8568b1d0 nt!ExFreePoolWithTag+0x2be

ee307b20 806f11f6 85ed4a80 ee307b54 f6fe7386 nt!MmFreeContiguousMemory+0x121

ee307b2c f6fe7386 85f791c8 00000200 05ed4a80 hal!HalFreeCommonBuffer+0xe

ee307b54 f6fcd896 85e50a80 804e59ec 8568b210 tabic!LiberaCommonBuffersPCI+0x76
[c:\icfnt\driversnt\tabic\dma.c @ 2644]

ee307ba4 f6fc11f2 85e50a80 8568b1d0 8568b264 tabic!TabicIoctlStartDMAEx+0x2d6
[c:\icfnt\driversnt\tabic\ioctl.c @ 2405]

ee307c34 804e3d77 85e509c8 8568b1d0 806ef2d0 tabic!TabicDispatch+0xc02
[c:\icfnt\driversnt\tabic\dispatch.c @ 542]

ee307c44 8056a9ab 8568b264 85e922e8 8568b1d0 nt!IopfCallDriver+0x31

ee307c58 8057d9f7 85e509c8 8568b1d0 85e922e8 nt!IopSynchronousServiceTail+0x60

ee307d00 8057fbfa 000007d4 00000000 00000000 nt!IopXxxControlFile+0x611

ee307d34 804df06b 000007d4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a

ee307d34 7c91eb94 000007d4 00000000 00000000 nt!KiFastCallEntry+0xf8

0012fac0 7c91d8ef 7c801671 000007d4 00000000 ntdll!KiFastSystemCallRet

0012fac4 7c801671 000007d4 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc

0012fb24 00401338 000007d4 9c40a16c 0012fe6c kernel32!DeviceIoControl+0xdd

WARNING: Stack unwind information not available. Following frames may be wrong.

0012fba8 004036fd 000007d4 9c40a16c 0012fe6c pru_tabic+0x1338

0012ff80 004077dc 00000002 00392860 003928a8 pru_tabic+0x36fd

0012ffc0 7c816d4f 0000001a 00000000 7ffde000 pru_tabic+0x77dc

0012fff0 00000000 004076e0 00000000 78746341 kernel32!BaseProcessStart+0x23

STACK_COMMAND: kb

FOLLOWUP_IP:

tabic!LiberaCommonBuffersPCI+76 [c:\icfnt\driversnt\tabic\dma.c @ 2644]

f6fe7386 8b4508 mov eax,dword ptr [ebp+8]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: tabic!LiberaCommonBuffersPCI+76

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: tabic

IMAGE_NAME: tabic.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 46287837

FAILURE_BUCKET_ID: 0x19_20_tabic!LiberaCommonBuffersPCI+76

BUCKET_ID: 0x19_20_tabic!LiberaCommonBuffersPCI+76

Followup: MachineOwner

---------

In WinDbg I can dump the entire memory range at 85ED4A80 (virtual address of
the common buffer passed to FreeCommonBuffer) everything seems OK (the common
buffer is 512 bytes long and is filled with 0x55). As suggested, I have enabled
driver verifier for my driver (tabic.sys). The problem is that with driver
verifier enabled the system does not crash.

Is there any way to search fro more information in the dump?

System is Windows XP SP2, WinDbg 6.6.0007.5, DDK 3790.1830

Best regards.

OSR_Community_User · April 20, 2007, 8:33am

Thanks Maxim.

The problem I have now is that with driver verifier special pool enabled for
my driver, the system does not bugcheck.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Maxim S. Shatskih
Enviado el: viernes, 20 de abril de 2007 14:22
Para: Windows System Software Devs Interest List
Asunto: Re:[ntdev] How to debug BugCheck 19

You have overwrote some memory via the stray pointer and spoiled the
pool
block headers.

Verifier’s Special Pool feature helps a lot.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Juli?n Rodr?guez” wrote in message
news:xxxxx@ntdev…
Dear friends.

I have a bugcheck in my driver.

BugCheck 19, {20, 85ed4a78, 85ed4c80, a410001}

Ourput from !analyze -v

kd> !analyze -v

*******************************************************************

Bugcheck Analysis

*************************************************************************

BAD_POOL_HEADER (19)

The pool is already corrupt at the time of the current request.

This may or may not be due to the caller.

The internal pool links must be walked to figure out a possible cause of

the problem, and then special pool applied to the suspect tags or the driver

verifier to a suspect driver.

Arguments:

Arg1: 00000020, a pool block header size is corrupt.

Arg2: 85ed4a78, The pool entry we were looking for within the page.

Arg3: 85ed4c80, The next pool entry.

Arg4: 0a410001, (reserved)

Debugging Details:

------------------

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: 85ed4a78 Nonpaged pool

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: pru_tabic.exe

LAST_CONTROL_TRANSFER: from 8054be41 to 805339ae

STACK_TEXT:

ee307ab4 8054be41 00000019 00000020 85ed4a78 nt!KeBugCheckEx+0x1b

ee307b04 80514cb1 85ed4a80 00000000 8568b1d0 nt!ExFreePoolWithTag+0x2be

ee307b20 806f11f6 85ed4a80 ee307b54 f6fe7386 nt!MmFreeContiguousMemory+0x121

ee307b2c f6fe7386 85f791c8 00000200 05ed4a80 hal!HalFreeCommonBuffer+0xe

ee307b54 f6fcd896 85e50a80 804e59ec 8568b210
tabic!LiberaCommonBuffersPCI+0x76
[c:\icfnt\driversnt\tabic\dma.c @ 2644]

ee307ba4 f6fc11f2 85e50a80 8568b1d0 8568b264
tabic!TabicIoctlStartDMAEx+0x2d6
[c:\icfnt\driversnt\tabic\ioctl.c @ 2405]

ee307c34 804e3d77 85e509c8 8568b1d0 806ef2d0 tabic!TabicDispatch+0xc02
[c:\icfnt\driversnt\tabic\dispatch.c @ 542]

ee307c44 8056a9ab 8568b264 85e922e8 8568b1d0 nt!IopfCallDriver+0x31

ee307c58 8057d9f7 85e509c8 8568b1d0 85e922e8
nt!IopSynchronousServiceTail+0x60

ee307d00 8057fbfa 000007d4 00000000 00000000 nt!IopXxxControlFile+0x611

ee307d34 804df06b 000007d4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a

ee307d34 7c91eb94 000007d4 00000000 00000000 nt!KiFastCallEntry+0xf8

0012fac0 7c91d8ef 7c801671 000007d4 00000000 ntdll!KiFastSystemCallRet

0012fac4 7c801671 000007d4 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc

0012fb24 00401338 000007d4 9c40a16c 0012fe6c kernel32!DeviceIoControl+0xdd

WARNING: Stack unwind information not available. Following frames may be
wrong.

0012fba8 004036fd 000007d4 9c40a16c 0012fe6c pru_tabic+0x1338

0012ff80 004077dc 00000002 00392860 003928a8 pru_tabic+0x36fd

0012ffc0 7c816d4f 0000001a 00000000 7ffde000 pru_tabic+0x77dc

0012fff0 00000000 004076e0 00000000 78746341 kernel32!BaseProcessStart+0x23

STACK_COMMAND: kb

FOLLOWUP_IP:

tabic!LiberaCommonBuffersPCI+76 [c:\icfnt\driversnt\tabic\dma.c @ 2644]

f6fe7386 8b4508 mov eax,dword ptr [ebp+8]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: tabic!LiberaCommonBuffersPCI+76

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: tabic

IMAGE_NAME: tabic.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 46287837

FAILURE_BUCKET_ID: 0x19_20_tabic!LiberaCommonBuffersPCI+76

BUCKET_ID: 0x19_20_tabic!LiberaCommonBuffersPCI+76

Followup: MachineOwner

---------

In WinDbg I can dump the entire memory range at 85ED4A80 (virtual address of
the common buffer passed to FreeCommonBuffer) everything seems OK (the
common
buffer is 512 bytes long and is filled with 0x55). As suggested, I have
enabled
driver verifier for my driver (tabic.sys). The problem is that with driver
verifier enabled the system does not crash.

Is there any way to search fro more information in the dump?

System is Windows XP SP2, WinDbg 6.6.0007.5, DDK 3790.1830

Best regards.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · April 20, 2007, 8:55am

Turn on the other verifications as well (at the very least use the standard settings). You can clobber memory by doing DMA writes to physical addresses no longer mapped, for instance, and you need the DMA verifications in addition to special pool to find these.

If I were you I’d also check the tags at the detected locations in the bugcheck to see if I could identify who they belonged to. Just for sanity’s sake.

OSR_Community_User · April 20, 2007, 9:00am

Should have reread the OP first- it looks like standard settings were already tried.

!pool 85ed4a80 ought to report the corruption, but it may also point to some interesting tags on that pool page (depending upon how bad the corruption is).

OSR_Community_User · April 20, 2007, 9:20am

Thanks Bob.

All verifications are on, except the low resources simulation. The tag seems
to be MedmCm (tag used by AllocateCommonBuffer?). !pool command shows “Pool
page [85ed4000] is __inVALID”. The card is not doing DMA at the moment of
the crash.

Best regards.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Bob Kjelgaard
Enviado el: viernes, 20 de abril de 2007 14:55
Para: Windows System Software Devs Interest List
Asunto: RE:[ntdev] How to debug BugCheck 19

Turn on the other verifications as well (at the very least use the standard
settings). You can clobber memory by doing DMA writes to physical addresses
no longer mapped, for instance, and you need the DMA verifications in
addition to special pool to find these.

If I were you I’d also check the tags at the detected locations in the
bugcheck to see if I could identify who they belonged to. Just for sanity’s
sake.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · April 20, 2007, 10:07am

It doesn’t have to be doing DMA at the time of the crash. This bugcheck is there because the header for your common buffer (which is in the 8 bytes preceding the buffer) has a corrupted size entry. Since it correctly determined the location of the next header, it would appear that the size of the previous header is the corrupted one. But my point about any corruptor is that it could have happened at ANY TIME between when you allocated the common buffer and when you freed it. If you did ANY DMA, it could have corrupted something- but if you used standard settings, all of that (except the point about WHEN the corruption could have occurred) is moot.

!pool will report that page as invalid if it is corrupted. So that’s to be expected. You already know it’s corrupted because this bugcheck is for a corrupted header on that page.

But it will also attempt to dump a list of all the pool allocations on that page, along with their tags. This means that, among other things, you can see what the allocation just before yours was, because if IT was overflowed, it would have corrupted your header. This IS what the bugcheck text is asking you to do- identify such tags and turn on special pool for them.

If the page is too corrupted, then the list won’t get that far, and you have to dump the entire page and examine it to see for yourself if you can piece together what may have corrupted it. I’m assuming that’s probably beyond your scope, or you wouldn’t have asked for this sort of assistance in the first place, so I didn’t bother to say so before. At that point, finding the culprit becomes exceedingly difficult, even for the most expert of analysts, because it involves analyzing the corrupted entry and trying various hypotheses against previously encountered patterns of corruption- that’s a lot longer post than I want to write, and I know there are people who are better at it than I am (and I usually do pretty well, if I can believe the feedback I get).

OSR_Community_User · April 23, 2007, 4:37am

Thanks for your response, Bob.

I know there is something bad in my driver that only happens under certain
circumstances. I hoped that driver verifier would bugcheck near the
corruption, but in this case this tool is of no use. I will review every bit
of my code, check whether there is any point not handling correct error
returns from system functions, etc. First think I will try to do is disable
DMA in hardware, been everything the same (allocations and deallocations).
Is just a matter of disable a WRITE_PORT_UCHAR. If this way the system does
not bugcheck, I think it is a good clue about were to look further.

Since I only develop this driver (and a lot of other things, TCP/IP
application protocols, GUIs, Database Access, communication protocols with
every kind of voice communications resource you can think of… I am not an
expert in device drivers (there are not much of you in the world, BTW),
maybe the problem is the card (a PCI card made in my company) is overriding
other system component’s memory.

Thanks to all of you.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Bob Kjelgaard
Enviado el: viernes, 20 de abril de 2007 16:07
Para: Windows System Software Devs Interest List
Asunto: RE: [ntdev] How to debug BugCheck 19

It doesn’t have to be doing DMA at the time of the crash. This bugcheck is
there because the header for your common buffer (which is in the 8 bytes
preceding the buffer) has a corrupted size entry. Since it correctly
determined the location of the next header, it would appear that the size of
the previous header is the corrupted one. But my point about any corruptor
is that it could have happened at ANY TIME between when you allocated the
common buffer and when you freed it. If you did ANY DMA, it could have
corrupted something- but if you used standard settings, all of that (except
the point about WHEN the corruption could have occurred) is moot.

!pool will report that page as invalid if it is corrupted. So that’s to be
expected. You already know it’s corrupted because this bugcheck is for a
corrupted header on that page.

But it will also attempt to dump a list of all the pool allocations on that
page, along with their tags. This means that, among other things, you can
see what the allocation just before yours was, because if IT was overflowed,
it would have corrupted your header. This IS what the bugcheck text is
asking you to do- identify such tags and turn on special pool for them.

If the page is too corrupted, then the list won’t get that far, and you have
to dump the entire page and examine it to see for yourself if you can piece
together what may have corrupted it. I’m assuming that’s probably beyond
your scope, or you wouldn’t have asked for this sort of assistance in the
first place, so I didn’t bother to say so before. At that point, finding
the culprit becomes exceedingly difficult, even for the most expert of
analysts, because it involves analyzing the corrupted entry and trying
various hypotheses against previously encountered patterns of corruption-
that’s a lot longer post than I want to write, and I know there are people
who are better at it than I am (and I usually do pretty well, if I can
believe the feedback I get).

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · April 23, 2007, 9:21am

I thought about your problem a bit over the weekend, and here are some other things that may be helpful.

(1) If you’ve still got the dump, post the output of !pool or a dump of the failed page (dc

l0x1000, or something to that effect). Someone may notice something there that can help.
(2) The size fields are fairly small (2 bytes IIRC)- perhaps this is a mask of bits on or off through a stale or uninitialized pointer? (Special pool can't always catch these, because they are random, rather than overflow/underflow).
(3) Is the driver code PreFast clean? PFD does a lot of checking and can point out a lot of errors of this sort (uninitialized data, overflows, etc) beyond what the compiler can tell you.

No test tool is perfect, but if you had the standard settings and were able to run tests with it, your DMA is probably good. Also, such an error usually trashes a LOT of memory, not just a couple of bytes in a header.

One last thing was that the tag you listed looked to be too big- tags should be 4 characters, not 6. I don't have a kernel debugger running currently, so I can't check the format directly, but two of those characters should actually be a size field (or flags- this has gone past my memory limits).

Thanks for the kind words, but I don't consider myself an expert- more of a somewhat competent dev who doesn't give up easily when it comes to debugging... I work with some of the real experts and I can tell the difference!

OSR_Community_User · April 23, 2007, 10:46am

Hi Bob.

I still have the dump. Output from !pool 85ed4000 10x1000:

Pool page 85ed4a78 region is Nonpaged pool
85ed4000 size: 80 previous size: 0 (Allocated) Mdl
85ed4080 size: 10 previous size: 80 (Free) …
85ed4090 size: 80 previous size: 10 (Allocated) Mdl
85ed4110 size: 40 previous size: 80 (Allocated) iGig
85ed4150 size: 80 previous size: 40 (Allocated) Mdl
85ed41d0 size: 28 previous size: 80 (Allocated) Ntfn
85ed41f8 size: 28 previous size: 28 (Allocated) FSfm
85ed4220 size: 8 previous size: 28 (Free) NtfI
85ed4228 size: 20 previous size: 8 (Allocated) Prcr
85ed4248 size: 20 previous size: 20 (Free) CPnp
85ed4268 size: d8 previous size: 20 (Allocated) MmCi
85ed4340 size: 28 previous size: d8 (Allocated) FSfm
85ed4368 size: 10 previous size: 28 (Free) NtfI
85ed4378 size: d8 previous size: 10 (Allocated) MmCi
85ed4450 size: 100 previous size: d8 (Allocated) NDmo
85ed4550 size: 290 previous size: 100 (Free) Irp
85ed47e0 size: 28 previous size: 290 (Allocated) FSfm
85ed4808 size: 28 previous size: 28 (Allocated) Ntfn
85ed4830 size: 18 previous size: 28 (Free) Irp
85ed4848 size: 40 previous size: 18 (Allocated) Ntfr
85ed4888 size: 68 previous size: 40 (Allocated) MmCa
85ed48f0 size: 28 previous size: 68 (Allocated) Ntfn
85ed4918 size: 40 previous size: 28 (Allocated) Ntfr
85ed4958 size: 98 previous size: 40 (Allocated) File (Protected)
85ed49f0 size: 30 previous size: 98 (Free) Irp
85ed4a20 size: 50 previous size: 30 (Allocated) Process: 8569eb20
85ed4a70 size: 8 previous size: 50 (Free) .d.
*85ed4a78 size: 208 previous size: 8 (Allocated) *MmCm
Pooltag MmCm : Calls made to MmAllocateContiguousMemory,
Binary : nt!mm
85ed4c80 is not a valid small pool allocation, checking large pool…
unable to get pool big page table - either wrong symbols or pool tagging is
disabled
85ed4c80 is freed (or corrupt) pool
Bad previous allocation size @85ed4c80, last size was 41

***
*** An error (or corruption) in the pool was detected;
*** Attempting to diagnose the problem.
***
*** Use !poolval 85ed4000 for more details.
***

Pool page [85ed4000] is __inVALID.

Analyzing linked list…
[85ed4a78 –> 85ed4ca8 (size = 0x230 bytes)]: Corrupt region

Scanning for single bit errors…

None found

Output from db 85ed4000 L1000

kd> db 85ed4000 L1000
85ed4000 00 00 10 0a 4d 64 6c 20-00 00 00 00 20 00 0c 00 …Mdl … …
85ed4010 00 00 00 00 0a 70 b1 85-00 70 b1 85 5c 00 00 00 …p…p….…
85ed4020 0a 00 00 00 17 5b 00 00-00 00 09 0b 00 00 00 00 …[…
85ed4030 9c 98 af f7 44 98 af f7-00 00 00 00 00 00 00 00 …D…
85ed4040 00 00 00 00 00 90 f3 85-00 00 00 00 00 00 00 00 …
85ed4050 00 00 00 00 00 00 00 00-a8 5d fc 85 00 00 00 00 …]…
85ed4060 00 00 00 00 00 00 00 00-e0 41 ed 85 98 17 fd 85 …A…
85ed4070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4080 10 00 02 00 00 00 00 00-88 e0 ec 85 88 a0 ed 85 …
85ed4090 02 00 10 0a 4d 64 6c 20-00 00 00 00 20 00 0c 00 …Mdl … …
85ed40a0 00 00 00 00 0a 60 b1 85-00 60 b1 85 5c 00 00 00 …...….…
85ed40b0 0a 00 00 00 16 5b 00 00-00 00 00 00 00 00 00 00 …[…
85ed40c0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed40d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed40e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed40f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4100 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4110 10 00 08 0a 69 47 69 67-98 e1 ec 85 98 40 ed 85 …iGig…@…
85ed4120 08 e0 ec 85 01 00 00 00-0a 60 b1 05 00 00 00 00 …`…
85ed4130 0a 60 b1 05 00 00 00 00-00 60 b1 05 00 00 00 00 .`…`…
85ed4140 0a 60 b1 85 00 60 b1 85-5c 00 00 00 00 00 00 00 .`…`….…
85ed4150 08 00 10 0a 4d 64 6c 20-00 00 00 00 20 00 0c 00 …Mdl … …
85ed4160 00 00 00 00 0e 70 b1 85-00 70 b1 85 00 08 00 00 …p…p…
85ed4170 0e 00 00 00 17 5b 00 00-00 00 00 00 00 00 00 00 …[…
85ed4180 00 00 00 00 00 00 00 00-78 b8 f7 85 00 00 00 00 …x…
85ed4190 bf be 53 f7 e8 94 af f7-04 00 00 00 00 00 00 00 …S…
85ed41a0 00 00 00 00 00 00 00 00-00 00 00 00 20 20 fd 85 … …
85ed41b0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed41c0 38 00 02 00 00 00 00 00-70 20 56 80 c8 a1 ed 85 8…p V…
85ed41d0 10 00 05 0a 4e 74 66 6e-07 07 1c 00 00 00 00 00 …Ntfn…
85ed41e0 00 00 00 00 f8 a1 ec 85-00 00 00 00 a8 95 e5 85 …
85ed41f0 00 21 fd 85 00 00 00 00-05 00 05 0a 46 53 66 6d .!..FSfm
85ed4200 01 00 00 00 54 d3 b1 f7-00 00 00 00 01 00 04 00 …T…
85ed4210 00 00 00 00 14 42 ed 85-14 42 ed 85 3d 00 00 00 …B…B…=…
85ed4220 05 00 01 00 4e 74 66 49-01 00 04 0a 50 72 63 72 …NtfI…Prcr
85ed4230 01 00 00 00 01 00 00 00-00 00 00 00 00 00 00 00 …
85ed4240 00 00 00 00 50 00 7b f7-04 00 04 00 43 50 6e 70 …P.{…CPnp
85ed4250 20 9a e5 85 90 4d 5a 85-00 00 00 00 08 30 ed 85 …MZ…0…
85ed4260 30 a0 fc 85 00 00 00 00-04 00 1b 0a 4d 6d 43 69 0…MmCi
85ed4270 c0 18 1e e4 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4280 0d 00 00 00 01 00 00 00-05 00 00 00 01 00 00 00 …
85ed4290 a0 00 00 01 30 44 6a 85-00 00 00 00 00 00 00 00 …0Dj…
85ed42a0 70 42 ed 85 11 00 00 00-00 00 00 00 02 00 00 00 pB…
85ed42b0 f8 18 1e e4 00 00 00 00-01 00 00 00 c0 42 ed 85 …B…
85ed42c0 70 42 ed 85 31 00 00 00-02 00 00 00 4c 00 00 00 pB…1…L…
85ed42d0 fc 18 1e e4 00 00 00 00-0a 00 00 00 e0 42 ed 85 …B…
85ed42e0 70 42 ed 85 51 00 00 00-4e 00 00 00 01 00 00 00 pB…Q…N…
85ed42f0 24 19 1e e4 00 00 00 00-01 00 00 00 00 43 ed 85 $…C…
85ed4300 70 42 ed 85 11 00 00 00-4f 00 00 00 03 00 00 00 pB…O…
85ed4310 28 19 1e e4 00 00 00 00-01 00 00 00 20 43 ed 85 (… C…
85ed4320 70 42 ed 85 11 00 00 00-52 00 00 00 03 00 00 00 pB…R…
85ed4330 2c 19 1e e4 00 00 00 00-01 00 00 00 00 00 00 00 ,…
85ed4340 1b 00 05 0a 46 53 66 6d-01 00 00 00 54 d3 b1 f7 …FSfm…T…
85ed4350 00 00 00 00 01 00 04 00-00 00 00 00 5c 43 ed 85 …\C…
85ed4360 5c 43 ed 85 3d 00 00 00-05 00 02 00 4e 74 66 49 \C…=…NtfI
85ed4370 e0 60 e9 85 a8 34 ee 85-02 00 1b 0a 4d 6d 43 69 .`…4…MmCi
85ed4380 b8 61 63 e1 00 00 00 00-00 00 00 00 01 00 00 00 .ac…
85ed4390 06 00 00 00 11 00 00 00-05 00 00 00 12 00 00 00 …
85ed43a0 a0 00 00 09 a8 6d f3 85-00 00 00 00 00 00 00 00 …m…
85ed43b0 80 43 ed 85 11 00 00 00-00 00 00 00 02 00 00 00 .C…
85ed43c0 f0 61 63 e1 00 00 00 00-01 00 00 00 d0 43 ed 85 .ac…C…
85ed43d0 80 43 ed 85 31 00 00 00-02 00 00 00 1d 00 00 00 .C…1…
85ed43e0 f4 61 63 e1 00 00 00 00-04 00 00 00 f0 43 ed 85 .ac…C…
85ed43f0 80 43 ed 85 51 00 00 00-1f 00 00 00 01 00 00 00 .C…Q…
85ed4400 04 62 63 e1 00 00 00 00-01 00 00 00 10 44 ed 85 .bc…D…
85ed4410 80 43 ed 85 11 00 00 00-20 00 00 00 03 00 00 00 .C… …
85ed4420 08 62 63 e1 00 00 00 00-01 00 00 00 30 44 ed 85 .bc…0D…
85ed4430 80 43 ed 85 11 00 00 00-23 00 00 00 02 00 00 00 .C…#…
85ed4440 0c 62 63 e1 00 00 00 00-01 00 00 00 00 00 00 00 .bc…
85ed4450 1b 00 20 0a 4e 44 6d 6f-48 71 ee 85 58 44 ed 85 … .NDmoHq…XD…
85ed4460 68 a9 e2 85 80 e3 e8 85-10 cc ec 85 08 a0 ee 85 h…
85ed4470 08 a0 ee 85 98 b3 e0 85-00 00 00 00 78 a9 e2 85 …x…
85ed4480 00 00 00 00 1c d5 e8 85-7b e8 50 f7 d5 4f 52 f7 …{.P…OR.
85ed4490 34 f2 81 f7 50 ea 81 f7-00 00 00 00 b8 01 82 f7 4…P…
85ed44a0 00 00 00 00 78 fd 81 f7-00 00 00 00 4f 62 52 f7 …x…ObR.
85ed44b0 56 6b 52 f7 b7 38 52 f7-de e9 81 f7 00 00 00 00 VkR…8R…
85ed44c0 b8 01 82 f7 00 00 42 00-02 00 00 00 00 00 00 00 …B…
85ed44d0 a8 e2 e8 85 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed44e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed44f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4500 00 00 00 00 00 00 00 00-00 00 00 00 01 00 00 00 …
85ed4510 08 a0 ee 85 00 00 00 00-00 00 00 00 ca 83 9f f7 …
85ed4520 6e f0 81 f7 76 f0 81 f7-34 f2 81 f7 de e9 81 f7 n…v…4…
85ed4530 44 f2 81 f7 34 45 ed 85-34 45 ed 85 3c 45 ed 85 D…4E…4E…<e…>85ed4540 3c 45 ed 85 00 00 00 00-00 00 00 00 00 00 00 00 <e…>85ed4550 20 00 52 00 49 72 70 20-18 97 e5 85 40 75 63 85 .R.Irp …@uc.
85ed4560 00 00 00 00 00 00 00 00-03 00 4f 02 54 68 72 e5 …O.Thr.
85ed4570 20 28 62 85 00 00 00 00-b0 b0 d0 ba 00 00 00 a0 (b…
85ed4580 00 00 00 00 00 00 00 00-06 00 70 00 01 00 00 00 …p…
85ed4590 90 45 ed 85 90 45 ed 85-98 45 ed 85 98 45 ed 85 .E…E…E…E…
85ed45a0 00 00 00 00 00 80 62 ee-00 00 00 00 00 00 00 00 …b…
85ed45b0 30 ac 62 ee 00 04 00 00-00 0a 00 10 bc 45 ed 85 0.b…E…
85ed45c0 bc 45 ed 85 c4 45 ed 85-c4 45 ed 85 20 13 64 85 .E…E…E… .d.
85ed45d0 00 00 00 00 03 00 00 00-00 00 00 00 02 01 00 00 …
85ed45e0 00 01 00 06 f8 45 ed 85-a8 97 e5 85 40 a4 55 80 …E…@.U.
85ed45f0 53 10 00 00 08 00 00 24-60 f5 5e 85 60 f5 5e 85 S…$`.^.`.^.
85ed4600 88 45 ed 85 58 f5 5e 85-40 46 ed 85 00 00 01 00 .E…X.^.@F…
85ed4610 00 00 00 00 00 00 00 00-88 45 ed 85 00 00 00 00 …E…
85ed4620 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4630 88 45 ed 85 00 00 00 00-00 00 00 00 00 00 00 00 .E…
85ed4640 80 46 ed 85 80 46 ed 85-88 45 ed 85 78 46 ed 85 .F…F…E…xF…
85ed4650 f8 45 ed 85 02 01 01 00-00 00 00 00 00 00 00 00 .E…
85ed4660 01 00 00 00 00 00 00 00-80 9b 55 80 00 00 00 00 …U…
85ed4670 00 00 00 00 00 00 00 00-08 00 0a 00 01 00 00 00 …
85ed4680 80 46 ed 85 80 46 ed 85-12 35 dd 26 00 00 00 00 .F…F…5.&…
85ed4690 50 98 e5 85 c0 9f ae f7-00 00 00 00 00 00 00 00 P…
85ed46a0 00 00 00 00 00 00 00 00-01 00 00 00 01 00 00 00 …
85ed46b0 00 00 01 00 00 00 00 00-00 00 00 00 64 ad 62 ee …d.b.
85ed46c0 bc 45 ed 85 d4 46 ed 85-01 01 00 00 00 00 00 00 .E…F…
85ed46d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed46e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed46f0 00 b0 62 ee 12 00 30 00-00 00 00 00 88 45 ed 85 …b…0…E…
85ed4700 bc 45 ed 85 bc 45 ed 85-41 a8 4f 80 95 cc 50 80 .E…E…A.O…P.
85ed4710 21 a8 4f 80 00 00 00 00-00 00 00 00 00 00 00 00 !.O…
85ed4720 00 00 00 00 05 00 05 00-00 00 00 00 2c 47 ed 85 …,G…
85ed4730 2c 47 ed 85 02 00 00 00-f8 98 e5 85 68 da e5 85 ,G…h…
85ed4740 00 00 00 00 00 00 00 00-50 6f 86 ec 28 19 3c 0e …Po…(.<.
85ed4750 f4 bb c7 4d 25 83 c7 01-00 00 00 00 5c 47 ed 85 …M%…\G…
85ed4760 5c 47 ed 85 00 00 00 00-00 00 00 00 6c 47 ed 85 \G…lG…
85ed4770 6c 47 ed 85 6c 05 00 00-dc 03 00 00 05 00 05 00 lG…l…
85ed4780 00 00 00 00 84 47 ed 85-84 47 ed 85 01 00 00 00 …G…G…
85ed4790 00 00 00 00 00 00 00 00-98 47 ed 85 98 47 ed 85 …G…G…
85ed47a0 00 00 00 00 00 00 00 00-20 13 64 85 56 08 81 7c … .d.V…|
85ed47b0 9a 31 4c 77 74 99 e5 85-e4 da e5 85 01 00 00 00 .1Lwt…
85ed47c0 00 00 00 00 00 00 00 00-07 00 00 00 ff 03 1f 00 …
85ed47d0 01 00 00 00 00 00 00 00-02 00 00 00 00 00 00 00 …
85ed47e0 52 00 05 0a 46 53 66 6d-01 00 00 00 54 d3 b1 f7 R…FSfm…T…
85ed47f0 00 00 00 00 01 00 04 00-00 00 00 00 fc 47 ed 85 …G…
85ed4800 fc 47 ed 85 3d 00 00 00-05 00 05 0a 4e 74 66 6e .G…=…Ntfn
85ed4810 07 07 1c 00 00 00 00 00-00 00 00 00 90 0d f3 85 …
85ed4820 00 00 00 00 88 17 df 85-00 21 fd 85 00 00 00 00 …!..
85ed4830 05 00 03 00 49 72 70 20-18 13 ee 85 b0 4c ed 85 …Irp …L…
85ed4840 03 04 00 00 00 00 00 00-03 00 08 0a 4e 74 66 72 …Ntfr
85ed4850 e8 22 ee 85 20 49 ed 85-00 00 00 00 00 00 00 00 .“… I…
85ed4860 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4870 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4880 00 00 00 00 00 00 00 00-08 00 0d 0a 4d 6d 43 61 …MmCa
85ed4890 a8 b0 67 e1 5c 22 ee 85-ac 22 ed 85 00 00 00 00 …g."…”…
85ed48a0 06 00 00 00 00 00 00 00-01 00 00 00 00 00 00 00 …
85ed48b0 80 00 00 09 70 23 ee 85-00 00 00 00 00 00 00 00 …p#…
85ed48c0 90 48 ed 85 60 00 00 c1-00 00 00 00 0d 00 00 00 .H…`…
85ed48d0 d8 2a 6f e1 00 00 00 00-0e 00 00 00 00 00 00 00 .*o…
85ed48e0 a8 22 ee 85 f8 22 ed 85-00 00 00 00 01 00 00 00 .“…”…
85ed48f0 0d 00 05 0a 4e 74 66 6e-07 07 1c 00 00 00 00 00 …Ntfn…
85ed4900 00 00 00 00 a8 22 ed 85-00 00 00 00 00 00 00 00 …“…
85ed4910 00 21 fd 85 00 00 00 00-05 00 08 0a 4e 74 66 72 .!..Ntfr
85ed4920 50 48 ed 85 68 22 ed 85-00 00 00 00 00 00 00 00 PH…h”…
85ed4930 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4940 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4950 00 00 00 00 00 00 00 00-08 00 13 0a 46 69 6c e5 …Fil.
85ed4960 00 00 00 00 00 00 00 00-01 00 00 00 00 00 00 00 …
85ed4970 60 25 fb 85 00 08 00 42-01 00 00 00 00 00 00 00 `%…B…
85ed4980 05 00 70 00 30 60 fd 85-80 6d fd 85 90 0d 68 e1 …p.0`…m…h.
85ed4990 e8 0e 68 e1 04 49 ed 85-00 00 00 00 00 00 00 00 …h…I…
85ed49a0 00 00 00 00 00 00 01 00-00 01 01 01 40 40 04 00 …@@…
85ed49b0 32 00 38 00 48 b2 67 e1-00 00 00 00 00 00 00 00 2.8.H.g…
85ed49c0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed49d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 04 00 …
85ed49e0 00 00 00 00 e4 49 ed 85-e4 49 ed 85 00 00 00 00 …I…I…
85ed49f0 13 00 06 00 49 72 70 20-d0 1b 60 85 70 f4 e5 85 …Irp …`.p…
85ed4a00 00 00 00 00 00 00 00 00-08 4a ed 85 08 4a ed 85 …J…J…
85ed4a10 00 00 00 00 00 02 00 00-00 01 03 04 00 00 00 04 …
85ed4a20 06 00 0a 1a 20 eb 69 85-07 00 00 00 00 00 00 00 … .i…
85ed4a30 00 00 00 00 48 3a f3 85-18 69 60 85 00 00 00 00 …H:…i`…
85ed4a40 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4a50 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4a60 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4a70 0a 00 01 00 20 13 64 85-01 00 41 0a 4d 6d 43 6d … .d…A.MmCm
85ed4a80 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4a90 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4aa0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4ab0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4ac0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4ad0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4ae0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4af0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b00 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b10 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b20 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b30 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b40 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b50 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b60 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b70 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b80 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4b90 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4ba0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4bb0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4bc0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4bd0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4be0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4bf0 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4c00 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4c10 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4c20 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4c30 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4c40 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4c50 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4c60 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4c70 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
85ed4c80 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff …
85ed4c90 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff …
85ed4ca0 9c 4c ed 85 3d 00 00 00-05 00 03 00 49 72 70 20 .L…=…Irp
85ed4cb0 38 48 ed 85 b0 0c ed 85-03 04 00 00 00 00 00 00 8H…
85ed4cc0 03 00 13 0a 46 69 6c e5-00 00 00 00 00 00 00 00 …Fil…
85ed4cd0 01 00 00 00 00 00 00 00-60 25 fb 85 00 08 00 42 …`%…B
85ed4ce0 01 00 00 00 00 00 00 00-05 00 70 00 30 60 fd 85 …p.0`…
85ed4cf0 80 6d fd 85 d0 00 68 e1-28 02 68 e1 1c 23 ed 85 .m…h.(.h…#…
85ed4d00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 01 00 …
85ed4d10 00 01 01 01 40 40 04 00-32 00 38 00 e8 b2 67 e1 …@@…2.8…g.
85ed4d20 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4d30 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4d40 00 00 00 00 00 00 04 00-00 00 00 00 4c 4d ed 85 …LM…
85ed4d50 4c 4d ed 85 00 00 00 00-13 00 0d 0a 4d 6d 43 61 LM…MmCa
85ed4d60 e8 b1 67 e1 ac 22 ed 85-3c 14 ed 85 00 00 00 00 …g…“…<…
85ed4d70 02 00 00 00 00 00 00 00-01 00 00 00 00 00 00 00 …
85ed4d80 80 00 00 09 e8 4c ed 85-00 00 00 00 00 00 00 00 …L…
85ed4d90 60 4d ed 85 60 00 00 20-00 00 00 00 02 00 00 00 `M…`… …
85ed4da0 18 2b 6f e1 00 00 00 00-03 00 00 00 00 00 00 00 .+o…
85ed4db0 f8 22 ed 85 88 14 ed 85-00 00 00 00 01 00 00 00 .”…
85ed4dc0 0d 00 05 0a 4e 74 66 6e-07 07 1c 00 00 00 00 00 …Ntfn…
85ed4dd0 00 00 00 00 38 14 ed 85-00 00 00 00 00 00 00 00 …8…
85ed4de0 00 21 fd 85 00 00 00 00-05 00 08 0a 4e 74 66 72 .!..Ntfr
85ed4df0 a0 23 ed 85 30 4e ed 85-00 00 00 00 00 00 00 00 .#…0N…
85ed4e00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4e10 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4e20 00 00 00 00 00 00 00 00-08 00 08 0a 4e 74 66 72 …Ntfr
85ed4e30 f0 4d ed 85 c8 14 ed 85-00 00 00 00 00 00 00 00 .M…
85ed4e40 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4e50 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4e60 00 00 00 00 00 00 00 00-08 00 02 00 49 72 70 20 …Irp
85ed4e70 d0 51 ed 85 00 09 ee 85-02 00 04 0a 56 61 64 53 .Q…VadS
85ed4e80 d0 35 00 00 df 35 00 00-10 09 ee 85 00 00 00 00 .5…5…
85ed4e90 e0 51 ed 85 10 00 00 c4-04 00 06 0a 45 76 65 ee .Q…Eve.
85ed4ea0 01 00 00 00 01 00 00 00-f8 3b fc 85 00 00 00 00 …;…
85ed4eb0 80 0c 56 80 00 00 00 00-01 00 04 00 00 00 00 00 …V…
85ed4ec0 c0 4e ed 85 c0 4e ed 85-06 00 27 0a 43 63 53 63 .N…N…'.CcSc
85ed4ed0 ff 02 30 01 01 00 00 00-00 10 00 00 00 00 00 00 …0…
85ed4ee0 e0 4e ed 85 e0 4e ed 85-00 00 10 00 00 00 00 00 .N…N…
85ed4ef0 ff ff ff ff ff ff ff 7f-ff ff ff ff ff ff ff 7f …
85ed4f00 e0 43 fb 85 00 00 00 00-00 00 00 00 00 00 00 00 .C…
85ed4f10 00 4f ed 85 f0 73 ed 85-00 00 00 00 00 00 00 00 .O…s…
85ed4f20 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4f30 00 00 00 00 54 47 fd 85-d4 a5 61 85 04 02 00 00 …TG…a…
85ed4f40 00 00 00 00 00 00 00 00-f8 31 2d e4 00 00 00 00 …1-…
85ed4f50 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4f60 ac b0 55 f7 20 8d 2d e4-f4 4f ed 85 f4 4f ed 85 …U. .-…O…O…
85ed4f70 b8 e7 4a e1 02 ba 55 f7-00 00 00 00 00 00 00 00 …J…U…
85ed4f80 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4f90 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4fa0 00 00 00 00 00 00 00 00-fe 02 00 00 ff 0f 00 00 …
85ed4fb0 f0 73 ed 85 00 00 00 00-00 00 00 00 00 00 00 00 .s…
85ed4fc0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4fd0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4fe0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
85ed4ff0 00 00 00 00 68 4f ed 85-68 4f ed 85 00 00 00 00 …hO…hO…

At 85ed4a78 there are 4 bytes I do not know their meaning. Then there are
another 4 bytes that seems to me like a memory tag MmCm
(MmAllocateContiguousMemory called from AllocateCommonBuffer?) and after
that there are 512 bytes with a 0x55 value (this is the value I use to
initialize my common buffers. Also 512 bytes is the size of my common buffer
in this scenario.

About the PREfast question, the only defects found are:

- warning 273: Format string mismatch: non-integer passed as parameter 3
when integer is required in call to ‘DbgPrint’. If a pointer value is being
passed, %p should be used, not %x, %d or any other format string because
only %p is designed to be used with pointer values on 64-bit platforms.
problem occurs in function ‘FreePool’ (many times in different functions).
- warning 53: Format string mismatch: extra argument passed to ‘DbgPrint’.
Parameter 4 is not used by the format string problem occurs in function
‘TabicSNICIoctlConfigLocalTimeslot’ (2 times in an IOCTL function).

After fixing this non critical warnings, result is the same.

Best regards.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Bob Kjelgaard
Enviado el: lunes, 23 de abril de 2007 15:20
Para: Windows System Software Devs Interest List
Asunto: RE: [ntdev] How to debug BugCheck 19

I thought about your problem a bit over the weekend, and here are some other
things that may be helpful.

(1) If you’ve still got the dump, post the output of !pool or a dump of the
failed page (dc l0x1000, or something to that effect). Someone
may notice something there that can help.
(2) The size fields are fairly small (2 bytes IIRC)- perhaps this is a mask
of bits on or off through a stale or uninitialized pointer? (Special pool
can’t always catch these, because they are random, rather than
overflow/underflow).
(3) Is the driver code PreFast clean? PFD does a lot of checking and can
point out a lot of errors of this sort (uninitialized data, overflows, etc)
beyond what the compiler can tell you.

No test tool is perfect, but if you had the standard settings and were able
to run tests with it, your DMA is probably good. Also, such an error
usually trashes a LOT of memory, not just a couple of bytes in a header.

One last thing was that the tag you listed looked to be too big- tags should
be 4 characters, not 6. I don’t have a kernel debugger running currently,
so I can’t check the format directly, but two of those characters should
actually be a size field (or flags- this has gone past my memory limits).

Thanks for the kind words, but I don’t consider myself an expert- more of a
somewhat competent dev who doesn’t give up easily when it comes to
debugging… I work with some of the real experts and I can tell the
difference!

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · April 23, 2007, 11:34am

Should have asked for that earlier, and saved some time (I misinterpreted which header was deemed corrupted).

There are 32 bytes of 0xff at the end of your buffer. They’ve overwritten the header and much of the next pool item (it is a 32 byte item, which may or not be relevant). The rest of the page appears to be intact.

Does that pattern mean anything to you? Do you ever write data to the common buffer in that pattern, perhaps running off the end in some cases? OR do you perhaps allocate a 32 byte item immediately after creating the common buffer, and perhaps underflow it [Special pool should have caught this, though]?

As far as the format, the first two bytes give the number of allocation units (8 bytes on x86) in the previous block, and the next two give the size of the following block (and also have flags indicating allocated /free state and other things I don’t recall). So 0100 is 0x1 previous block (hence the size of 8), while 410a is a size of 0x41 with flags of 0x0a 0x41 * 8 = 0x208… Note that to cover a block of more than 2K bytes, you need to pick up a bit from the next byte of size info, so it isn’t just “one byte size, one byte flags”.

>
*85ed4a78 size: 208 previous size: 8 (Allocated) *MmCm
…
85ed4c80 is freed (or corrupt) pool
Bad previous allocation size @85ed4c80, last size was 41

Analyzing linked list…
[85ed4a78 –> 85ed4ca8 (size = 0x230 bytes)]: Corrupt region
85ed4c70 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
<<

This is where the next header should have been

>
85ed4c80 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff …
85ed4c90 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff …
<<
This has the last 8 bytes of the allocated item (or free space, no way to tell), but the previous items size on the Irp tag is consistent with everything else, meaning just the one header has been clobbered.
>
85ed4ca0 9c 4c ed 85 3d 00 00 00-05 00 03 00 49 72 70 20 .L…=…Irp
<<

Previous size at 85ed4ca8 = 0x5 units (0x28 bytes), so the previous header would be 85ed4c80, which matches up. I spot checked a few of the remaining items, (and the command already did that when it identified the corrupt region), and it appears just one item was clobbered, including its header.

OSR_Community_User · April 23, 2007, 12:00pm

One last bit of info I can glean from the dump.

May not be relevant, but it looks like whatever was clobbered (the 32-byte item) probably had a LIST_ENTRY at offset 0x14 (because the first DWORD at 85edca0 [which would be offset 0x18] is 85ed4c9c, which would be the correct address for such an entry, and they get initialized with both pointers to the base address of the entry). If there’s a concern the item was corrupted directly, that might help identify what it was. There could be other reasons for that pointer, but that’s got a fairly high probability because it is a common practice. A incorrectly coded CONTAINING_RECORD usage based off such an entry, for instance, might lead to something like this (problem is this is off into hypotheticals- there can be an awful lot of those). Prefast couldn’t catch it- not sure anything can.

>
85ed4ca0 9c 4c ed 85 3d 00 00 00-05 00 03 00 49 72 70 20 .L…=…Irp
<<

OSR_Community_User · April 23, 2007, 1:03pm

Hi Bob.

Sorry for not consider this 32 bytes block just after the common buffer.
This means a lot to me, since the hardware writes to DMA in 32 bytes blocks.
Also, as the common buffer is used for many different 8000Hz PCM audio
channels, my driver maintains a couple of buffers for reading and writing to
and from the common buffer for every audio channel. In DpcForISR I copy
memory from channel buffer to common buffer and vice versa in 32 bytes
blocks. Now I can debug it live (if it is my driver’s fault as I think), or
check with the hardware team if the hardware is writing past the common
buffer, since the conditions that make the system to bugcheck are known to
us.

I just wonder why DriverVerifier does not stops in this kind of buffer
overrun, and why with DriverVerifier’s special pool enabled the system does
not bugcheck.

Many thanks for your valuable help Bob.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Bob Kjelgaard
Enviado el: lunes, 23 de abril de 2007 17:33
Para: Windows System Software Devs Interest List
Asunto: RE: [ntdev] How to debug BugCheck 19

Should have asked for that earlier, and saved some time (I misinterpreted
which header was deemed corrupted).

There are 32 bytes of 0xff at the end of your buffer. They’ve overwritten
the header and much of the next pool item (it is a 32 byte item, which may
or not be relevant). The rest of the page appears to be intact.

Does that pattern mean anything to you? Do you ever write data to the
common buffer in that pattern, perhaps running off the end in some cases?
OR do you perhaps allocate a 32 byte item immediately after creating the
common buffer, and perhaps underflow it [Special pool should have caught
this, though]?

As far as the format, the first two bytes give the number of allocation
units (8 bytes on x86) in the previous block, and the next two give the size
of the following block (and also have flags indicating allocated /free state
and other things I don’t recall). So 0100 is 0x1 previous block (hence the
size of 8), while 410a is a size of 0x41 with flags of 0x0a 0x41 * 8 =
0x208… Note that to cover a block of more than 2K bytes, you need to pick
up a bit from the next byte of size info, so it isn’t just “one byte size,
one byte flags”.

>
*85ed4a78 size: 208 previous size: 8 (Allocated) *MmCm
…
85ed4c80 is freed (or corrupt) pool
Bad previous allocation size @85ed4c80, last size was 41

Analyzing linked list…
[85ed4a78 –> 85ed4ca8 (size = 0x230 bytes)]: Corrupt region
85ed4c70 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
<<

This is where the next header should have been

>
85ed4c80 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff …
85ed4c90 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff …
<<
This has the last 8 bytes of the allocated item (or free space, no way to
tell), but the previous items size on the Irp tag is consistent with
everything else, meaning just the one header has been clobbered.
>
85ed4ca0 9c 4c ed 85 3d 00 00 00-05 00 03 00 49 72 70 20 .L…=…Irp
<<

Previous size at 85ed4ca8 = 0x5 units (0x28 bytes), so the previous header
would be 85ed4c80, which matches up. I spot checked a few of the remaining
items, (and the command already did that when it identified the corrupt
region), and it appears just one item was clobbered, including its header.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · April 23, 2007, 1:23pm

Special pool can’t reliably detect problems with DMA writes to memory, because those go to physical addresses, and as long as there’s memory physically there, it’s going to get written. Special pool can only reliably detect overflows through virtual addresses (memory being written from your driver code).

That said, if you set the global flags to force buffers to the start of each special pool page (by default they align at the end of a page), this MIGHT have been detected (but probably not any sooner than the original bugcheck, because checks are only done when you free the memory, as I recall it).

Also, special pool can be exhausted, in which case normal pool is used (probably not the case, here, but it can happen).

You DID reboot after changing the verifier settings, right? Vista allows some settings to change without reboot, but all the earlier OS’s require it.

I would have expected the DMA verifier mechanisms to catch this, although I’m not familiar with how common buffer gets handled. IIRC scatter-gather requests are forced to double buffer with pattern filled guard pages on either end to catch these- had to debug a few places where it caught an audio driver misbehaving.

Perhaps someone else here is expert enough to give you better information on that.

OSR_Community_User · April 23, 2007, 1:45pm

Yes, I am an idiot (happens all the time, I’m used to it :-).

Presumably can’t catch the common buffer case because you don’t have to do all the happy mapping stuff involved with scatter-gather. Meaning there’d be nothing to instrument (no API calls, etc) to aid in detection. The bugcheck you got is about as good a detection as you can get in this case.

At any rate, the handful of times I’ve touched drivers with common buffer DMA, nothing was broken, meaning I never had to really dig into it to any depth. So don’t rely too heavily on this info.

Calvin_Guan · April 23, 2007, 2:55pm

The best tool to catch DMA overshoot is bus analyzer. A 32B (8-DWORD) overshoot is most likely you have a bug in the driver that did program the DMA address right or the hardware has a serious bug that fail to determine the DMA region. If the overshoot is less than 4B, then take a closer look at the BE# logic of your hardware.

Also note that DV DMA verifier might give you a double-copy buffer to DMA so that it would mask off the problem when enabled.

HTH,
Calvin Guan
NetXtreme NTX Miniport
Broadcom Corporation
Connecting Everything?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-284379-
xxxxx@lists.osr.com] On Behalf Of Juli?n Rodr?guez Bajo
Sent: Monday, April 23, 2007 10:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to debug BugCheck 19

Hi Bob.

Sorry for not consider this 32 bytes block just after the common buffer.
This means a lot to me, since the hardware writes to DMA in 32 bytes
blocks.
Also, as the common buffer is used for many different 8000Hz PCM audio
channels, my driver maintains a couple of buffers for reading and writing
to
and from the common buffer for every audio channel. In DpcForISR I copy
memory from channel buffer to common buffer and vice versa in 32 bytes
blocks. Now I can debug it live (if it is my driver’s fault as I think),
or
check with the hardware team if the hardware is writing past the common
buffer, since the conditions that make the system to bugcheck are known to
us.

I just wonder why DriverVerifier does not stops in this kind of buffer
overrun, and why with DriverVerifier’s special pool enabled the system
does
not bugcheck.

Many thanks for your valuable help Bob.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Bob Kjelgaard
Enviado el: lunes, 23 de abril de 2007 17:33
Para: Windows System Software Devs Interest List
Asunto: RE: [ntdev] How to debug BugCheck 19

Should have asked for that earlier, and saved some time (I misinterpreted
which header was deemed corrupted).

There are 32 bytes of 0xff at the end of your buffer. They’ve overwritten
the header and much of the next pool item (it is a 32 byte item, which may
or not be relevant). The rest of the page appears to be intact.

Does that pattern mean anything to you? Do you ever write data to the
common buffer in that pattern, perhaps running off the end in some cases?
OR do you perhaps allocate a 32 byte item immediately after creating the
common buffer, and perhaps underflow it [Special pool should have caught
this, though]?

As far as the format, the first two bytes give the number of allocation
units (8 bytes on x86) in the previous block, and the next two give the
size
of the following block (and also have flags indicating allocated /free
state
and other things I don’t recall). So 0100 is 0x1 previous block (hence
the
size of 8), while 410a is a size of 0x41 with flags of 0x0a 0x41 * 8 =
0x208… Note that to cover a block of more than 2K bytes, you need to
pick
up a bit from the next byte of size info, so it isn’t just “one byte size,
one byte flags”.

>>
*85ed4a78 size: 208 previous size: 8 (Allocated) *MmCm
…
85ed4c80 is freed (or corrupt) pool
Bad previous allocation size @85ed4c80, last size was 41

Analyzing linked list…
[85ed4a78 –> 85ed4ca8 (size = 0x230 bytes)]: Corrupt region
85ed4c70 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55
UUUUUUUUUUUUUUUU
<<

This is where the next header should have been
>>
85ed4c80 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff …
85ed4c90 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff …
<<
This has the last 8 bytes of the allocated item (or free space, no way to
tell), but the previous items size on the Irp tag is consistent with
everything else, meaning just the one header has been clobbered.
>>
85ed4ca0 9c 4c ed 85 3d 00 00 00-05 00 03 00 49 72 70 20 .L…=…Irp
<<

Previous size at 85ed4ca8 = 0x5 units (0x28 bytes), so the previous header
would be 85ed4c80, which matches up. I spot checked a few of the
remaining
items, (and the command already did that when it identified the corrupt
region), and it appears just one item was clobbered, including its header.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · April 25, 2007, 4:21am

Thanks Bob for all your suggestions.

I really appreciate your help. Yesterday I was ill, so I did not have time
to study about the 32 bytes long sequence. I will investigate today. I hope
the issue to be solved quickly, since the bugckeck only happens when I
enable just 1 8000Hz audio channel (not a common scenario in any of our real
systems, so I think this problem has been there since our ISA card and ISA
driver times, 10 years ago.).

Best regards.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Bob Kjelgaard
Enviado el: lunes, 23 de abril de 2007 19:45
Para: Windows System Software Devs Interest List
Asunto: RE: [ntdev] How to debug BugCheck 19

Yes, I am an idiot (happens all the time, I’m used to it :-).

Presumably can’t catch the common buffer case because you don’t have to do
all the happy mapping stuff involved with scatter-gather. Meaning there’d
be nothing to instrument (no API calls, etc) to aid in detection. The
bugcheck you got is about as good a detection as you can get in this case.

At any rate, the handful of times I’ve touched drivers with common buffer
DMA, nothing was broken, meaning I never had to really dig into it to any
depth. So don’t rely too heavily on this info.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · April 25, 2007, 4:26am

Thanks Calvin.

This give us an additional cue.

Best regards.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Calvin (Hao) Guan
Enviado el: lunes, 23 de abril de 2007 20:54
Para: Windows System Software Devs Interest List
Asunto: RE: [ntdev] How to debug BugCheck 19

The best tool to catch DMA overshoot is bus analyzer. A 32B (8-DWORD)
overshoot is most likely you have a bug in the driver that did program the
DMA address right or the hardware has a serious bug that fail to determine
the DMA region. If the overshoot is less than 4B, then take a closer look at
the BE# logic of your hardware.

Also note that DV DMA verifier might give you a double-copy buffer to DMA so
that it would mask off the problem when enabled.

HTH,
Calvin Guan
NetXtreme NTX Miniport
Broadcom Corporation
Connecting Everything?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-284379-
xxxxx@lists.osr.com] On Behalf Of Juli?n Rodr?guez Bajo
Sent: Monday, April 23, 2007 10:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to debug BugCheck 19

Hi Bob.

Sorry for not consider this 32 bytes block just after the common buffer.
This means a lot to me, since the hardware writes to DMA in 32 bytes
blocks.
Also, as the common buffer is used for many different 8000Hz PCM audio
channels, my driver maintains a couple of buffers for reading and writing
to
and from the common buffer for every audio channel. In DpcForISR I copy
memory from channel buffer to common buffer and vice versa in 32 bytes
blocks. Now I can debug it live (if it is my driver’s fault as I think),
or
check with the hardware team if the hardware is writing past the common
buffer, since the conditions that make the system to bugcheck are known to
us.

I just wonder why DriverVerifier does not stops in this kind of buffer
overrun, and why with DriverVerifier’s special pool enabled the system
does
not bugcheck.

Many thanks for your valuable help Bob.

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Bob Kjelgaard
Enviado el: lunes, 23 de abril de 2007 17:33
Para: Windows System Software Devs Interest List
Asunto: RE: [ntdev] How to debug BugCheck 19

Should have asked for that earlier, and saved some time (I misinterpreted
which header was deemed corrupted).

There are 32 bytes of 0xff at the end of your buffer. They’ve overwritten
the header and much of the next pool item (it is a 32 byte item, which may
or not be relevant). The rest of the page appears to be intact.

Does that pattern mean anything to you? Do you ever write data to the
common buffer in that pattern, perhaps running off the end in some cases?
OR do you perhaps allocate a 32 byte item immediately after creating the
common buffer, and perhaps underflow it [Special pool should have caught
this, though]?

As far as the format, the first two bytes give the number of allocation
units (8 bytes on x86) in the previous block, and the next two give the
size
of the following block (and also have flags indicating allocated /free
state
and other things I don’t recall). So 0100 is 0x1 previous block (hence
the
size of 8), while 410a is a size of 0x41 with flags of 0x0a 0x41 * 8 =
0x208… Note that to cover a block of more than 2K bytes, you need to
pick
up a bit from the next byte of size info, so it isn’t just “one byte size,
one byte flags”.

>>
*85ed4a78 size: 208 previous size: 8 (Allocated) *MmCm
…
85ed4c80 is freed (or corrupt) pool
Bad previous allocation size @85ed4c80, last size was 41

Analyzing linked list…
[85ed4a78 –> 85ed4ca8 (size = 0x230 bytes)]: Corrupt region
85ed4c70 55 55 55 55 55 55 55 55-55 55 55 55 55 55 55 55
UUUUUUUUUUUUUUUU
<<

This is where the next header should have been
>>
85ed4c80 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff
…
85ed4c90 ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff
…
<<
This has the last 8 bytes of the allocated item (or free space, no way to
tell), but the previous items size on the Irp tag is consistent with
everything else, meaning just the one header has been clobbered.
>>
85ed4ca0 9c 4c ed 85 3d 00 00 00-05 00 03 00 49 72 70 20 .L…=…Irp
<<

Previous size at 85ed4ca8 = 0x5 units (0x28 bytes), so the previous header
would be 85ed4c80, which matches up. I spot checked a few of the
remaining
items, (and the command already did that when it identified the corrupt
region), and it appears just one item was clobbered, including its header.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · April 26, 2007, 11:23am

Dear friends.

After following your suggestions, especially from Bob, the problem is fixed
now. It was the on board FPGA writing out of the common buffer area when
AllocateCommonBuffer returned a no page aligned logical address.

Best regards and many thanks to all of you.