poolval address argument?

NTDEV
1

Hi,

I’m trying to track down a bug which I believe exists in the WDK
Serial.sys sample driver. This bug causes the system to crash with a
corrupt pool.

I’ve used gflags and verifier.exe to enable pool checks for my drivers
(including my modified serial.sys).

I break a running system in WinDbg, then use:
!verifier 3
…which shows a “PoolAddress” for serial.sys.

Is this the address I need to use in the “!poolval” command?

Because it always shows invalid, and a dump of that memory shows receive
buffer contents at that address. Given that the machine won’t crash unless
the serial ports are hammered, I can’t believe that every serial I/O
transaction corrupts the pool. It’s more likely that this address is not
really the pool header, but the pool memory buffer?!?

Is that so?

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

2

Can you send the output of !analyze -v of the suspected corruption?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark McDougall
Sent: Monday, May 07, 2007 6:52 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] poolval address argument?

Hi,

I’m trying to track down a bug which I believe exists in the WDK
Serial.sys sample driver. This bug causes the system to crash with a
corrupt pool.

I’ve used gflags and verifier.exe to enable pool checks for my drivers
(including my modified serial.sys).

I break a running system in WinDbg, then use:
!verifier 3
…which shows a “PoolAddress” for serial.sys.

Is this the address I need to use in the “!poolval” command?

Because it always shows invalid, and a dump of that memory shows
receive
buffer contents at that address. Given that the machine won’t crash
unless
the serial ports are hammered, I can’t believe that every serial I/O
transaction corrupts the pool. It’s more likely that this address is not
really the pool header, but the pool memory buffer?!?

Is that so?

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

—
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</http:>

3

Doron Holan wrote:

Can you send the output of !analyze -v of the suspected corruption?

I can, and will, as soon as I set up the environment again. This issue has
been put on the back-burner for a day or so…

BTW the corruption is reported in random drivers - anything but
serial.sys. I’ve seen it in ntfs.sys and sr.sys (IIRC).

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

4

Are you using the driver w/out modification or have you made changes to
it?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark McDougall
Sent: Monday, May 07, 2007 10:55 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] poolval address argument?

Doron Holan wrote:

Can you send the output of !analyze -v of the suspected corruption?

I can, and will, as soon as I set up the environment again. This issue
has
been put on the back-burner for a day or so…

BTW the corruption is reported in random drivers - anything but
serial.sys. I’ve seen it in ntfs.sys and sr.sys (IIRC).

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

—
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</http:>

5

Doron Holan wrote:

Can you send the output of !analyze -v of the suspected corruption?

kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_CORRUPTED_MMPOOL (d0)
Arguments:
Arg1: 20736920, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 8052dadf, address which referenced memory
An attempt was made to access a pageable (or completely invalid) address
at an
interrupt request level (IRQL) that is too high. This is
caused by drivers that have corrupted the system pool. Run the driver
verifier against any new (or suspect) drivers, and if that doesn’t turn up
the culprit, then use gflags to enable special pool. You can also set
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\ProtectNonPagedPool
to a DWORD 1 value and reboot. Then the system will unmap freed nonpaged
pool,
preventing drivers (although not DMA-hardware) from corrupting the pool.

Debugging Details:

WRITE_ADDRESS: 20736920

CURRENT_IRQL: 2

FAULTING_IP:
nt!MiAllocatePoolPages+15f
8052dadf 8901 mov dword ptr [ecx],eax

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD0

PROCESS_NAME: System

TRAP_FRAME: f78be618 – (.trap fffffffff78be618)
ErrCode = 00000002
eax=73696874 ebx=8053e2e8 ecx=20736920 edx=00000001 esi=82587000 edi=00000001
eip=8052dadf esp=f78be68c ebp=f78be6c0 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!MiAllocatePoolPages+0x15f:
8052dadf 8901 mov dword ptr [ecx],eax
ds:0023:20736920=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 804ee7fe to 80515de4

STACK_TEXT:
f78be1c8 804ee7fe 00000003 00000000 000000d0 nt!RtlpBreakWithStatusInstruction
f78be214 804ef0ba 00000003 20736920 8052dadf nt!KiBugCheckDebugBreak+0x19
f78be5dc 804ef559 000000d0 20736920 00000002 nt!KeBugCheck2+0x43c
f78be5fc 8052b629 0000000a 20736920 00000002 nt!KeBugCheckEx+0x19
f78be5fc 8052dadf 0000000a 20736920 00000002 nt!KiTrap0E+0x219
f78be6c0 8052f97b 00000000 c45e7000 00000000 nt!MiAllocatePoolPages+0x15f
f78be728 baeb543f 00000004 00001000 3966744e nt!ExAllocatePoolWithTag+0x109
f78be768 baeb50d2 f78be96c e1bd9568 00000000 Ntfs!NtfsCreateMdlAndBuffer+0x43
f78be95c baeb34e7 f78be96c 9a947e48 0110070a Ntfs!NtfsCommonWrite+0x17e0
f78bead0 804e6215 82a7d678 9a947e48 8069d524 Ntfs!NtfsFsdWrite+0xf3
f78beae0 80625490 9a947e48 82a75960 82a85e88 nt!IopfCallDriver+0x31
f78beb04 baf483b8 82a85dd0 82a85d00 f78beb48 nt!IovCallDriver+0x9e
f78beb14 804e6215 82a85dd0 9a947e48 8069d524 sr!SrWrite+0xa8
f78beb24 80625490 826db830 00000000 82a85dd0 nt!IopfCallDriver+0x31
f78beb48 804e72cf f78bed50 f78beb84 00000000 nt!IovCallDriver+0x9e
f78beb5c 80500292 826db809 f78beb84 f78bec18 nt!IoSynchronousPageWrite+0xad
f78bec34 80500bc6 e1f3c008 e1f3c00c 00000019 nt!MiFlushSectionInternal+0x378
f78bec70 804dc410 8278b7e0 e1f3c008 00000000 nt!MmFlushSection+0x1b4
f78becf4 804dc70f 00001000 00000000 00000001 nt!CcFlushCache+0x33e
f78bed34 804de9f0 82aba290 80541480 82ab9b30 nt!CcWriteBehind+0xd7
f78bed74 80520c34 82aba290 00000000 82ab9b30 nt!CcWorkerThread+0x116
f78bedac 805a33ec 82aba290 00000000 00000000 nt!ExpWorkerThread+0xfe
f78beddc 8052cb16 80520b36 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
sr!SrWrite+a8
baf483b8 5f pop edi

SYMBOL_STACK_INDEX: c

SYMBOL_NAME: sr!SrWrite+a8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: sr

IMAGE_NAME: sr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3b7d85f6

FAILURE_BUCKET_ID: 0xD0_W_VRF_sr!SrWrite+a8

BUCKET_ID: 0xD0_W_VRF_sr!SrWrite+a8

Followup: MachineOwner

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

6

Doron Holan wrote:

Are you using the driver w/out modification or have you made changes to
it?

I have made minor changes to it, as instructed by yourself a few
weeks/months ago.

The changes involve the dispatching of interrupts from a bus driver, which
creates the PDOs to which this serial.sys attaches. The driver also
obtains the register base memory address from the bus driver.

I have also identified 1 bug in the original MS code - namely the
WRITE_TRANSMIT_FIFO_HOLDING macro in serial.h which only handles
port-mapped UARTs.

FWIW I have enabled the pool checking functionality in the driver verifier
and enabled tagging in gflags etc, but nothing is trapped as a direct
result of either the bus or serial drivers.

My question remains:

From the !verifier output, is the “PoolAddress” the correct value to
specify in the !poolval debugger extension command - because it always
returns ‘invalid’ and I can see that the “header” is trashed with the UART
receive data…

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

7

Doron Holan wrote:

Are you using the driver w/out modification or have you made changes to
it?

I think I might be onto something…

I notice the driver uses MCR:OUT2 to gate interrupts… that won’t work in
my opencores 16550 UARTS instantiated inside an FPGA… :frowning:

The plot thickens…

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

8

Mark McDougall wrote:

I think I might be onto something…
I notice the driver uses MCR:OUT2 to gate interrupts… that won’t work in
my opencores 16550 UARTS instantiated inside an FPGA… :frowning:
The plot thickens…

Nope - same problem! :frowning:

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>