When .crash is used to create memory dump all is good but when NotMyFault.exe(From sysinternals) application is used then as soon as WdfDpcEnqueue() is invoked in the driver code the system reboots.
Curious to know why the system rebooted when WdfDpcEnqueue() is invoked.
In both the cases, this path is hit from BugCheck callback and called at HIGH_IRQL.
From MSDN WdfDpcEnqueue() can be called from any IRQL.
Checked the params passed to WdfDpcEnqueue() and are valid.
I have assumed that this isn’t posted and submitted,
http://www.osronline.com/showthread.cfm?link=283289
Please close this.
Regardless of doc loopholes, your bugcheck callback should not call
WdfDpcEnqueue. What do you think this call is going to accomplish? The
system is not going to run any dpcs. The bugcheck code is all running at
IRQ HIGH_LEVEL. No interrupts, no dpcs. If there is code in your dpc
routine that you need to execute, you need to re-arrange your driver so
that you can run that code from your bugcheck callback directly. As there
is no way to synchronize with any other code running on any other
processor, (all of which are not executing anymore anyway) you had better
be able to get your device into a safe state from your bugcheck callback
using register operations and polling mechanisms, or just forget about
interacting with the device at all.
Mark Roddy
On Thu, Apr 20, 2017 at 5:23 AM, wrote:
> I have assumed that this isn’t posted and submitted,
> http://www.osronline.com/showthread.cfm?link=283289
>
> Please close this.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
Hi Mark,
I understood your points and fixed my code not calling WdfDpcEnqueue.
The reason for my post is to know the probable reasons for the system reboots when the same code path at same IRQL is exercised with NotMyFault and why it completes collecting memory dump with .crash.
Curiosity.
There is a function xyz() which is called from many places in the driver, also the same function is invoked from the BugCheck callback function.
Scenario A: - If the bugcheck happens by invoking .crash from the debugger. All is good. Which means the WdfDpcEnqueue() enqueues a dpc(of course which never never gets called) and the bugcheck call back continues.
Scenario B: But, if the bugcheck is caused using NotMyFault application(from Sysinternals) then as soon as WdfDpcEnqueue() is executed the system reboots.(The bugcheck callback isn’t completed)
I am not able to understand the difference between scenario A & B for this different behavior. Also, WdfDpcEnqueue() can be called at any IRQ Level, but why the system rebooted when WdfDpcEnqueue() is executed ?
Checked the validity of the DPC(parameter of WdfDpcEnqueue()) and it’s valid.
xxxxx@gmail.com wrote:
There is a function xyz() which is called from many places in the driver, also the same function is invoked from the BugCheck callback function.
Scenario A: - If the bugcheck happens by invoking .crash from the debugger. All is good. Which means the WdfDpcEnqueue() enqueues a dpc(of course which never never gets called) and the bugcheck call back continues.
Scenario B: But, if the bugcheck is caused using NotMyFault application(from Sysinternals) then as soon as WdfDpcEnqueue() is executed the system reboots.(The bugcheck callback isn’t completed)
I am not able to understand the difference between scenario A & B for this different behavior. Also, WdfDpcEnqueue() can be called at any IRQ Level, but why the system rebooted when WdfDpcEnqueue() is executed ?
Honestly, the fundamental answer is “it doesn’t matter”. Your only
action is “don’t do that”.
The system does a bugcheck because the kernel is damaged. That’s WHY
the operating system is being killed – the kernel and its data
structures are in an inconsistent state. You can’t do ANYTHING in a
bugcheck handler that relies on intact kernel data structures. It might
explode, it might not. The fact that it happens to work sometimes
should not provide you any comfort. What you’re doing is WRONG and you
need to stop it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
As i mentioned in earlier comment, i have fixed my code already.
But only curios to know why .crash consistently never shows up this problem and with NotMyFault.exe it consistently fails.
I understand your explanation of inconsistent kernel.
Absolutely not looking for any solution. Just trying to see if anything new available to learn wrto this scenario.