Please help with this crashdump

This crash dump is my only lead (for now)
I don't understand it. Where is the instruction pointer, it seems to be 0.
And virtually there is no stack trace because the first frame is not found
If you can understand any of this please help out :)

1: kd> !analyze -v

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

* *

* Bugcheck Analysis *

* *

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

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

An attempt was made to access a pageable (or completely invalid) address at
an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If kernel debugger is available get stack backtrace.

Arguments:

Arg1: 00000000, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 00000000, address which referenced memory

Debugging Details:

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



READ_ADDRESS: 00000000

CURRENT_IRQL: 2

FAULTING_IP:

+0

00000000 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from f6100b6c to 00000000

STACK_TEXT:

f38a0b74 f6100b6c 86278008 8627df58 8627dfb8 0x0

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

f38a0ba4 f60f7385 858dfc48 00000011 f38a0bd4 fwdrv+0xcb6c

f38a0bb4 f60f5d25 858dfc48 864b0a08 864acca8 fwdrv+0x3385

f38a0bd4 f60f5d7e 864067e8 f38a0bec f60f639b fwdrv+0x1d25

f38a0be0 f60f639b 864067e8 f38a0bfc f60f5116 fwdrv+0x1d7e

f38a0bec f60f5116 864067e8 00000139 f38a0c14 fwdrv+0x239b

f38a0bfc f60f68de 864067e8 00000139 f38a0c94 fwdrv+0x1116

f38a0c14 f60f6c28 86585210 00000020 0000000e fwdrv+0x28de

f38a0c30 f60f6d76 864b3af0 86585210 f38a0c64 fwdrv+0x2c28

f38a0c40 804eb3c1 864b3af0 86585210 806bb2cc fwdrv+0x2d76

f38a0c50 805644d2 86585280 8652e0e0 86585210 nt!IopfCallDriver+0x31

f38a0c64 805651f6 864b3af0 86585210 8652e0e0
nt!IopSynchronousServiceTail+0x5e

f38a0d00 8055e288 000000a4 00000000 00000000 nt!IopXxxControlFile+0x5a6

f38a0d34 805306a4 000000a4 00000000 00000000 nt!NtDeviceIoControlFile+0x28

f38a0d34 7ffe0304 000000a4 00000000 00000000 nt!KiSystemService+0xc9

00f1ddbc 00000000 00000000 00000000 00000000
SharedUserData!SystemCallStub+0x4



FAILED_INSTRUCTION_ADDRESS:

+0

00000000 ?? ???

FOLLOWUP_IP:

fwdrv+cb6c

f6100b6c 8945f8 mov [ebp-0x8],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fwdrv+cb6c

MODULE_NAME: fwdrv

IMAGE_NAME: fwdrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3cbaab4f

STACK_COMMAND: kb

BUCKET_ID: 0xD1_CODE_AV_BAD_IP_fwdrv+cb6c

Followup: MachineOwner

---------

Mark
Sun Nov 16 12:57:21 CST 2003

On Sun, 16 Nov 2003 17:23:07 +0100, "Zuka" <askme@formyemail.com>
wrote:

>This crash dump is my only lead (for now)
>I don't understand it. Where is the instruction pointer, it seems to be 0.
>And virtually there is no stack trace because the first frame is not found
>If you can understand any of this please help out :)
>

You need to fixup windbg with the correct symbols for 'fwdrv', which I
assume is your contribution to this mess.

You have jumped to location zero, most likely by calling a null
pointer to function, although there are other ways to do this, I
suppose. The attempt to read the instruction at 0 in order to execute
it has resulted in the bugcheck, as the page here is protected
explicitly to trap bad programmer on device. Remember: new code is
crappy code.

In fact DRIVER_IRQL_NOT_LESS_OR_EQUAL ought to be renamed
BAD_PROGRAMMER_ON_DEVICE as it would be much clearer what the problem
was.



>1: kd> !analyze -v
>
>****************************************************************************
>***
>
>* *
>
>* Bugcheck Analysis *
>
>* *
>
>****************************************************************************
>***
>
>DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
>
>An attempt was made to access a pageable (or completely invalid) address at
>an
>
>interrupt request level (IRQL) that is too high. This is usually
>
>caused by drivers using improper addresses.
>
>If kernel debugger is available get stack backtrace.
>
>Arguments:
>
>Arg1: 00000000, memory referenced
>
>Arg2: 00000002, IRQL
>
>Arg3: 00000000, value 0 = read operation, 1 = write operation
>
>Arg4: 00000000, address which referenced memory
>
>Debugging Details:
>
>------------------
>
>
>
>READ_ADDRESS: 00000000
>
>CURRENT_IRQL: 2
>
>FAULTING_IP:
>
>+0
>
>00000000 ?? ???
>
>DEFAULT_BUCKET_ID: DRIVER_FAULT
>
>BUGCHECK_STR: 0xD1
>
>LAST_CONTROL_TRANSFER: from f6100b6c to 00000000
>
>STACK_TEXT:
>
>f38a0b74 f6100b6c 86278008 8627df58 8627dfb8 0x0
>
>WARNING: Stack unwind information not available. Following frames may be
>wrong.
>
>f38a0ba4 f60f7385 858dfc48 00000011 f38a0bd4 fwdrv+0xcb6c
>
>f38a0bb4 f60f5d25 858dfc48 864b0a08 864acca8 fwdrv+0x3385
>
>f38a0bd4 f60f5d7e 864067e8 f38a0bec f60f639b fwdrv+0x1d25
>
>f38a0be0 f60f639b 864067e8 f38a0bfc f60f5116 fwdrv+0x1d7e
>
>f38a0bec f60f5116 864067e8 00000139 f38a0c14 fwdrv+0x239b
>
>f38a0bfc f60f68de 864067e8 00000139 f38a0c94 fwdrv+0x1116
>
>f38a0c14 f60f6c28 86585210 00000020 0000000e fwdrv+0x28de
>
>f38a0c30 f60f6d76 864b3af0 86585210 f38a0c64 fwdrv+0x2c28
>
>f38a0c40 804eb3c1 864b3af0 86585210 806bb2cc fwdrv+0x2d76
>
>f38a0c50 805644d2 86585280 8652e0e0 86585210 nt!IopfCallDriver+0x31
>
>f38a0c64 805651f6 864b3af0 86585210 8652e0e0
>nt!IopSynchronousServiceTail+0x5e
>
>f38a0d00 8055e288 000000a4 00000000 00000000 nt!IopXxxControlFile+0x5a6
>
>f38a0d34 805306a4 000000a4 00000000 00000000 nt!NtDeviceIoControlFile+0x28
>
>f38a0d34 7ffe0304 000000a4 00000000 00000000 nt!KiSystemService+0xc9
>
>00f1ddbc 00000000 00000000 00000000 00000000
>SharedUserData!SystemCallStub+0x4
>
>
>
>FAILED_INSTRUCTION_ADDRESS:
>
>+0
>
>00000000 ?? ???
>
>FOLLOWUP_IP:
>
>fwdrv+cb6c
>
>f6100b6c 8945f8 mov [ebp-0x8],eax
>
>FOLLOWUP_NAME: MachineOwner
>
>SYMBOL_NAME: fwdrv+cb6c
>
>MODULE_NAME: fwdrv
>
>IMAGE_NAME: fwdrv.sys
>
>DEBUG_FLR_IMAGE_TIMESTAMP: 3cbaab4f
>
>STACK_COMMAND: kb
>
>BUCKET_ID: 0xD1_CODE_AV_BAD_IP_fwdrv+cb6c
>
>Followup: MachineOwner
>
>---------
>




=====================
Mark Roddy
Windows XP/2000/NT Consulting, Microsoft DDK MVP
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com
For Windows Device Driver Training: see www.azius.com

Zuka
Sun Nov 16 13:41:31 CST 2003

A call to a null-function pointer, was probably it. I found this was the
instruction before the return adress of the call that crashed
f6100b69 ff5114 call dword ptr [ecx+0x14]


This fwdrv.sys is firewall driver Kerio and I doubt I can ever get symbols
for it. fwdrv.sys is an IM driver. My driver is another NDIS IM driver in
the stack, but I don't see it anywhere in the stack backtrace.


Thanx :)

"Mark Roddy" <mroddy@tellink.net> wrote in message
news:qqhfrvgjcq7oo8ue2mqgsvla7i16q8lfuh@4ax.com...
> On Sun, 16 Nov 2003 17:23:07 +0100, "Zuka" <askme@formyemail.com>
> wrote:
>
> >This crash dump is my only lead (for now)
> >I don't understand it. Where is the instruction pointer, it seems to be
0.
> >And virtually there is no stack trace because the first frame is not
found
> >If you can understand any of this please help out :)
> >
>
> You need to fixup windbg with the correct symbols for 'fwdrv', which I
> assume is your contribution to this mess.
>
> You have jumped to location zero, most likely by calling a null
> pointer to function, although there are other ways to do this, I
> suppose. The attempt to read the instruction at 0 in order to execute
> it has resulted in the bugcheck, as the page here is protected
> explicitly to trap bad programmer on device. Remember: new code is
> crappy code.
>
> In fact DRIVER_IRQL_NOT_LESS_OR_EQUAL ought to be renamed
> BAD_PROGRAMMER_ON_DEVICE as it would be much clearer what the problem
> was.
>
>
>
> >1: kd> !analyze -v
> >
>
>***************************************************************************
*
> >***
> >
> >* *
> >
> >* Bugcheck Analysis *
> >
> >* *
> >
>
>***************************************************************************
*
> >***
> >
> >DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> >
> >An attempt was made to access a pageable (or completely invalid) address
at
> >an
> >
> >interrupt request level (IRQL) that is too high. This is usually
> >
> >caused by drivers using improper addresses.
> >
> >If kernel debugger is available get stack backtrace.
> >
> >Arguments:
> >
> >Arg1: 00000000, memory referenced
> >
> >Arg2: 00000002, IRQL
> >
> >Arg3: 00000000, value 0 = read operation, 1 = write operation
> >
> >Arg4: 00000000, address which referenced memory
> >
> >Debugging Details:
> >
> >------------------
> >
> >
> >
> >READ_ADDRESS: 00000000
> >
> >CURRENT_IRQL: 2
> >
> >FAULTING_IP:
> >
> >+0
> >
> >00000000 ?? ???
> >
> >DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> >BUGCHECK_STR: 0xD1
> >
> >LAST_CONTROL_TRANSFER: from f6100b6c to 00000000
> >
> >STACK_TEXT:
> >
> >f38a0b74 f6100b6c 86278008 8627df58 8627dfb8 0x0
> >
> >WARNING: Stack unwind information not available. Following frames may be
> >wrong.
> >
> >f38a0ba4 f60f7385 858dfc48 00000011 f38a0bd4 fwdrv+0xcb6c
> >
> >f38a0bb4 f60f5d25 858dfc48 864b0a08 864acca8 fwdrv+0x3385
> >
> >f38a0bd4 f60f5d7e 864067e8 f38a0bec f60f639b fwdrv+0x1d25
> >
> >f38a0be0 f60f639b 864067e8 f38a0bfc f60f5116 fwdrv+0x1d7e
> >
> >f38a0bec f60f5116 864067e8 00000139 f38a0c14 fwdrv+0x239b
> >
> >f38a0bfc f60f68de 864067e8 00000139 f38a0c94 fwdrv+0x1116
> >
> >f38a0c14 f60f6c28 86585210 00000020 0000000e fwdrv+0x28de
> >
> >f38a0c30 f60f6d76 864b3af0 86585210 f38a0c64 fwdrv+0x2c28
> >
> >f38a0c40 804eb3c1 864b3af0 86585210 806bb2cc fwdrv+0x2d76
> >
> >f38a0c50 805644d2 86585280 8652e0e0 86585210 nt!IopfCallDriver+0x31
> >
> >f38a0c64 805651f6 864b3af0 86585210 8652e0e0
> >nt!IopSynchronousServiceTail+0x5e
> >
> >f38a0d00 8055e288 000000a4 00000000 00000000 nt!IopXxxControlFile+0x5a6
> >
> >f38a0d34 805306a4 000000a4 00000000 00000000
nt!NtDeviceIoControlFile+0x28
> >
> >f38a0d34 7ffe0304 000000a4 00000000 00000000 nt!KiSystemService+0xc9
> >
> >00f1ddbc 00000000 00000000 00000000 00000000
> >SharedUserData!SystemCallStub+0x4
> >
> >
> >
> >FAILED_INSTRUCTION_ADDRESS:
> >
> >+0
> >
> >00000000 ?? ???
> >
> >FOLLOWUP_IP:
> >
> >fwdrv+cb6c
> >
> >f6100b6c 8945f8 mov [ebp-0x8],eax
> >
> >FOLLOWUP_NAME: MachineOwner
> >
> >SYMBOL_NAME: fwdrv+cb6c
> >
> >MODULE_NAME: fwdrv
> >
> >IMAGE_NAME: fwdrv.sys
> >
> >DEBUG_FLR_IMAGE_TIMESTAMP: 3cbaab4f
> >
> >STACK_COMMAND: kb
> >
> >BUCKET_ID: 0xD1_CODE_AV_BAD_IP_fwdrv+cb6c
> >
> >Followup: MachineOwner
> >
> >---------
> >
>
>
>
>
> =====================
> Mark Roddy
> Windows XP/2000/NT Consulting, Microsoft DDK MVP
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
> markr@hollistech.com
> For Windows Device Driver Training: see www.azius.com

Mark
Sun Nov 16 17:39:17 CST 2003

On Sun, 16 Nov 2003 20:41:31 +0100, "Zuka" <askme@formyemail.com>
wrote:

>A call to a null-function pointer, was probably it. I found this was the
>instruction before the return adress of the call that crashed
>f6100b69 ff5114 call dword ptr [ecx+0x14]
>
>
>This fwdrv.sys is firewall driver Kerio and I doubt I can ever get symbols
>for it. fwdrv.sys is an IM driver. My driver is another NDIS IM driver in
>the stack, but I don't see it anywhere in the stack backtrace.
>
>


That doesn't mean you didn't cause the damage. I'd turn driver
verifier loose on both of these drivers and see if it incriminates
anyone.



=====================
Mark Roddy
Windows XP/2000/NT Consulting, Microsoft DDK MVP
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com
For Windows Device Driver Training: see www.azius.com

Zuka
Sun Nov 16 17:36:42 CST 2003

I'm running driver verifier at the moment, but I haven't got this Kerio
firewall (fwdrv.sys) installed on my computer. Hope that verifier comes up
with something anyway.




"Mark Roddy" <mroddy@tellink.net> wrote in message
news:ri2grv4nv05m0k14qss7iu6olpppi654k5@4ax.com...
> On Sun, 16 Nov 2003 20:41:31 +0100, "Zuka" <askme@formyemail.com>
> wrote:
>
> >A call to a null-function pointer, was probably it. I found this was the
> >instruction before the return adress of the call that crashed
> >f6100b69 ff5114 call dword ptr [ecx+0x14]
> >
> >
> >This fwdrv.sys is firewall driver Kerio and I doubt I can ever get
symbols
> >for it. fwdrv.sys is an IM driver. My driver is another NDIS IM driver in
> >the stack, but I don't see it anywhere in the stack backtrace.
> >
> >
>
>
> That doesn't mean you didn't cause the damage. I'd turn driver
> verifier loose on both of these drivers and see if it incriminates
> anyone.
>
>
>
> =====================
> Mark Roddy
> Windows XP/2000/NT Consulting, Microsoft DDK MVP
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
> markr@hollistech.com
> For Windows Device Driver Training: see www.azius.com

Zuka
Sun Nov 16 19:46:40 CST 2003

Driververifier showed me that fwdrv.sys had a deadlock problem. I didn't get
any more info, cause it's "potentially deadlocking" all the time. It's a
deadlock bugcheck 1001. Thread 1 locks A B and thread 2 locks B and then A.

Could this kind of deadlock, somehow, cause the crash that I'm analyzing in
this crashdump here ?



"Mark Roddy" <mroddy@tellink.net> wrote in message
news:ri2grv4nv05m0k14qss7iu6olpppi654k5@4ax.com...
> On Sun, 16 Nov 2003 20:41:31 +0100, "Zuka" <askme@formyemail.com>
> wrote:
>
> >A call to a null-function pointer, was probably it. I found this was the
> >instruction before the return adress of the call that crashed
> >f6100b69 ff5114 call dword ptr [ecx+0x14]
> >
> >
> >This fwdrv.sys is firewall driver Kerio and I doubt I can ever get
symbols
> >for it. fwdrv.sys is an IM driver. My driver is another NDIS IM driver in
> >the stack, but I don't see it anywhere in the stack backtrace.
> >
> >
>
>
> That doesn't mean you didn't cause the damage. I'd turn driver
> verifier loose on both of these drivers and see if it incriminates
> anyone.
>
>
>
> =====================
> Mark Roddy
> Windows XP/2000/NT Consulting, Microsoft DDK MVP
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
> markr@hollistech.com
> For Windows Device Driver Training: see www.azius.com

Kirk
Sun Nov 16 20:24:42 CST 2003

"Zuka" <askme@formyemail.com> wrote in message
news:OtHOv6KrDHA.2636@TK2MSFTNGP09.phx.gbl...
> Driververifier showed me that fwdrv.sys had a deadlock problem. I didn't
get
> any more info, cause it's "potentially deadlocking" all the time. It's a
> deadlock bugcheck 1001. Thread 1 locks A B and thread 2 locks B and then
A.

Note that driver verifier cannot guarantee that a deadlock is real. E.g.
those threads might never get executed simultaneously.

> Could this kind of deadlock, somehow, cause the crash that I'm analyzing
in
> this crashdump here ?

I doubt that. Since the original problem was the bugcheck D1 you can try
!verifier to see the IRQL tracking data.

-Kirk