Hi all,
In my previous mail I had said that there is no trace of my driver in the
stack trace I do. The driver still crashes with IRQL_NOT_LESS_OR_EQUAL
error code. And bumps upon a breakpoint in the RtlAllocateHeapSlowly in
ntoskrnl. But I am still not able to find out the problem area.
Can anybody tell me whats happening?
Regards.
Hi there,
What you can do is the following:
Add on strategic points in your code a message what you have done and where
you have entered/left a function. When doing this you can find out where
the problem lies globally. When you also use binary bits to enable or
disable a specific debugmessage popping up you can specify on which
action/section in your driver the fault is to be reported. Add a timer
which checks your registry once a second and you will be able to get
specific debug logging at the moment you start an action where you expect a
BSOD to happen. Connect a Serial/IEEE cable and you’re halfways
Best regards,
Marco van Nieuwenhoven
ThunderStore
At 06:03 AM 3/6/2002 -0500, you wrote:
Hi all,
In my previous mail I had said that there is no trace of my driver in the
stack trace I do. The driver still crashes with IRQL_NOT_LESS_OR_EQUAL
error code. And bumps upon a breakpoint in the RtlAllocateHeapSlowly in
ntoskrnl. But I am still not able to find out the problem area.Can anybody tell me whats happening?
Regards.
You are currently subscribed to windbg as: xxxxx@thunderstore.com
To unsubscribe send a blank email to %%email.unsub%%
Gee, how many times has this list seen that? “there is no trace of my driver
in the stack trace …”
So? Since there is “No trace of your driver in the stack”, does that mean it
ain’t your driver causing the problem? Since you are asking the question I
think not. Your driver did something, or is doing something, that is causing
heartburn in the system. It very possibly completed an IRP when it shouldn’t
have, and when the IRP is then later referenced it looks like someone else
has the problem.
!analyze -v helps by the way, and can many times point you to the critical
point in your driver. What you need to do is pay very close attention to how
you are synchronizing and serializing access to your IRPs and any queues
that they may be on.
My money is on the fact that you completed an IRP when you shouldn’t have
and didn’t pop it from all referencing queues.
Although … I did see this once when I was allocating memory using the size
of the pointer to a structure, and then clearing the size of the structure.
Oh my was that nasty.
–
Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net
wrote in message news:xxxxx@windbg…
>
> Hi all,
>
> In my previous mail I had said that there is no trace of my driver in the
> stack trace I do. The driver still crashes with IRQL_NOT_LESS_OR_EQUAL
> error code. And bumps upon a breakpoint in the RtlAllocateHeapSlowly in
> ntoskrnl. But I am still not able to find out the problem area.
>
> Can anybody tell me whats happening?
>
> Regards.
>
>
>