Hi
For the DRIVER_IRQL_NOT_LESS_OR_EQUAL I always enable the special pool. This is a good way of tracking what is going on. Just do a search @ search.microsoft.com and put in special pool. Once you have that enabled, then you will be able to much more in your dump.
WIth regards to the memory dumps we choose:
- Let the custopmer send the dump in on a cd/FTP and we can then anaylze the dump with piece and take our time (Up to your management to give you some silence to figure this out)
- We ask our customer to install debug tools for windows and load the dump. Then we would www.webex
Kernel Debugging Interest List digest wrote:
WINDBG Digest for Wednesday, October 22, 2003.
1. Re: memory.dmp
2. Tracking down cause of page fault
3. RE: Tracking down cause of page fault
----------------------------------------------------------------------
Subject: Re: memory.dmp
From: “Stanislav Kolar”
Date: Wed, 22 Oct 2003 09:01:05 +0200
X-Message-Number: 1
Thank you for your suggestion, but:
a) we don’t want to bother user about uploading useless dumps (dumps are
quite big and not all users have high-speed connection)
b) we don’t want to raise presumption that our software is so buggy 
btw currently we are using the same approach you describe…
Stanislav Kolar
senior developer
…
Kerio Technologies
Sedlackova 16, 301 11 Plzen
tel. 37 733 8901, fax 37 733 8921
www.kerio.cz www.winroute.cz
…
No Pasarán!
----- Original Message -----
From: “WinDbg”
To: “Kernel Debugging Interest List”
Sent: Tuesday, October 21, 2003 6:00 PM
Subject: [windbg] Re: memory.dmp
>
> > We need to analyze the memory dump automatically on the
> > customer’s computer
> > to show him our dialog that our driver has been crashed and ask him if
he
> > wants to upload the memory.dmp file to our server. We of course cannot
> > assume that he has debugging tools installed…
>
> My suggestion is to always upload, and then run the analysis automated on
> your side. Just let the user know that you upload data, and have a
checkbox
> that lets him turn that off (privacy concern).
>
> Cheers,
>
> / h+
>
>
> —
> You are currently subscribed to windbg as: xxxxx@kerio.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
----------------------------------------------------------------------
Subject: Tracking down cause of page fault
From: “Will Barker”
Date: Wed, 22 Oct 2003 17:24:23 +0100
X-Message-Number: 2
I’m currently examing a problem with a driver that at some point causes a
BSOD due to a DRIVER_IRQL_NOT_LESS_OR_EQUAL . What I would like to do is get
the help of
WinDbg in telling me why the address that I am using may have become
invalid.
The sequence is
1) app issues a Read to my driver’s device which is configured for
DO_DIRECT_IO
2) I take the mdl and use MmGetSystemAddressForMdlSafe (Irp->MdlAddress,
HighPagePriority) to get a system address that I can use within the driver
at any IRQL. This address should reference nonpaged memory (i.e. the buffer
supplied in the read request)
3) Subsequent read requests are queued (using a section of the read buffer
which is now owned by the driver until the read request completes) - I know
I could just
queue the Irps themselves but that’s another story
4) So, I now have a queue of read buffers and at some, seemingly random
point, one of these pointers suddenly becomes invalid and, when used, causes
the BSOD.
I have numerous calls to a validation routine from within the driver which
is how I know that
a) when the BSOD occurs the address is the same value that was previously OK
(i.e. the last time the validation routine was called)
b) the address has become invalid when none of my driver code is running
(and the app has apparently done nothing either)
It looks like it has been paged out - but how could that be?
!analyze -v shows:
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pagable (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: fb1bab56, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f8778113, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: fb1bab56 Nonpaged pool
CURRENT_IRQL: 2
This clearly shows the address refering to nonpaged pool and yet fb1bab56 is
displayed as ??? if dumped (and was OK the last time the validation
routine was called)
Any suggestions as to any info I can gleem concerning this address and the
memory it references and why it should have become invalid?
Thanks
Will
----------------------------------------------------------------------
Subject: RE: Tracking down cause of page fault
From: “Curless, Jeffrey”
Date: Wed, 22 Oct 2003 14:10:55 -0400
X-Message-Number: 3
Silly question… but are you completing the read IRPs after chaining the
read requests?
-Jeff
-----Original Message-----
From: Will Barker [mailto:xxxxx@farsite.co.uk]
Sent: Wednesday, October 22, 2003 12:24 PM
To: Kernel Debugging Interest List
Subject: [windbg] Tracking down cause of page fault
I’m currently examing a problem with a driver that at some point causes a
BSOD due to a DRIVER_IRQL_NOT_LESS_OR_EQUAL . What I would like to do is get
the help of WinDbg in telling me why the address that I am using may have
become invalid.
The sequence is
1) app issues a Read to my driver’s device which is configured for
DO_DIRECT_IO
2) I take the mdl and use MmGetSystemAddressForMdlSafe (Irp->MdlAddress,
HighPagePriority) to get a system address that I can use within the driver
at any IRQL. This address should reference nonpaged memory (i.e. the buffer
supplied in the read request)
3) Subsequent read requests are queued (using a section of the read buffer
which is now owned by the driver until the read request completes) - I know
I could just queue the Irps themselves but that’s another story
4) So, I now have a queue of read buffers and at some, seemingly random
point, one of these pointers suddenly becomes invalid and, when used, causes
the BSOD.
I have numerous calls to a validation routine from within the driver which
is how I know that
a) when the BSOD occurs the address is the same value that was previously OK
(i.e. the last time the validation routine was called)
b) the address has become invalid when none of my driver code is running
(and the app has apparently done nothing either)
It looks like it has been paged out - but how could that be?
!analyze -v shows:
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pagable (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: fb1bab56, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f8778113, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: fb1bab56 Nonpaged pool
CURRENT_IRQL: 2
This clearly shows the address refering to nonpaged pool and yet fb1bab56 is
displayed as ??? if dumped (and was OK the last time the validation
routine was called)
Any suggestions as to any info I can gleem concerning this address and the
memory it references and why it should have become invalid?
Thanks
Will
—
You are currently subscribed to windbg as: xxxxx@concord.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
the latest virus scan software available for the presence of computer
viruses.
—
END OF DIGEST
—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Want to chat instantly with your online friends? Get the FREE Yahoo!Messenger