Hi,
I am debugging a NDIS-WDM driver under the verifier and am
seeing bugchecks in other modules. I am sure these are
caused by some memory corruption by my driver but I can’t
figure out which function is causing the error.
The host and the target are WinXP systems and I am using the
latest WinDbg (6.4.0004.3).
The latest crash had these details:
BUGCHECK_STR: 0xA
Arg1: 000000b8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 804dddc2, address which referenced memory
LAST_CONTROL_TRANSFER: from 804dde30 to 804dddc2
TRAP_FRAME: f9c87cf4 – (.trap fffffffff9c87cf4)
STACK_TEXT:
f9c87d6c 804dde30 81484020 81484060 f9c87da4 nt!MiSessionOutSwapProcess+0x23
f9c87d84 804def43 81484020 00000000 81946b30 nt!MmOutSwapProcess+0x20
f9c87da4 804def71 00484068 8057dfe1 00000000 nt!KiOutSwapProcesses+0x58
f9c87dac 8057dfe1 00000000 00000000 00000000 nt!KeSwapProcessOrStack+0x5d
f9c87ddc 80512c12 804eb368 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
How do I locate the code that caused the problem?
Thanks,
If you know in advance what is the virtual address of something that’s
getting stepped on, you can set a write breakpoint. Generally, though, it’s
not so easy. In fact, there’s no simple answer in such a case. Without a
predictable address to break on, you may have to resort to code inspection.
–
James Antognini
Windows DDK Support
This posting is provided “AS IS” with no warranties, and confers no rights.
“Harshal Chhaya” wrote in message
news:xxxxx@windbg…
>
> Hi,
>
> I am debugging a NDIS-WDM driver under the verifier and am
> seeing bugchecks in other modules. I am sure these are
> caused by some memory corruption by my driver but I can’t
> figure out which function is causing the error.
>
> The host and the target are WinXP systems and I am using the
> latest WinDbg (6.4.0004.3).
>
>
> The latest crash had these details:
>
> BUGCHECK_STR: 0xA
> Arg1: 000000b8, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000001, value 0 = read operation, 1 = write operation
> Arg4: 804dddc2, address which referenced memory
>
> LAST_CONTROL_TRANSFER: from 804dde30 to 804dddc2
>
> TRAP_FRAME: f9c87cf4 – (.trap fffffffff9c87cf4)
>
> STACK_TEXT:
> f9c87d6c 804dde30 81484020 81484060 f9c87da4
> nt!MiSessionOutSwapProcess+0x23
> f9c87d84 804def43 81484020 00000000 81946b30 nt!MmOutSwapProcess+0x20
> f9c87da4 804def71 00484068 8057dfe1 00000000 nt!KiOutSwapProcesses+0x58
> f9c87dac 8057dfe1 00000000 00000000 00000000 nt!KeSwapProcessOrStack+0x5d
> f9c87ddc 80512c12 804eb368 00000000 00000000
> nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> How do I locate the code that caused the problem?
>
> Thanks,
> - Harshal
>