Call to ExAllocatePoolWithTag() in my crash_dump driver NEVER RETURNS

Hi all,

I have written my crashdump virtual miniport driver. This crashdump driver works fine for complete, kernel, and mini dumps. However, OCASSIONALLY, the BSOD screen hangs with dump at 0% when tested in Windows Server 2016.

When I debugged using WinDbg, it is showing that the call to ExAllocatePoolWithTag() NEVER RETURNS. It stays there indefinitely. Please find the below function call:

pDeviceExtension->pcmdbuf=(struct mycmdrsp *)ExAllocatePoolWithTag(NonPagedPoolCacheAligned,pNum_bytes,‘MTAG’);

After this call, I am checking for NULL as follows:

if(pDeviceExtension->pcmdbuf == NULL)
{

}

However, since this call to ExAllocatePoolWithTag() does not returns, I am not sure what could be the reason, and unable to get some lead to this problem.

Please help.
Thanks in advance.

You can’t do allocations at crash dump time, you need to have pre-allocated
all your memory for that.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, March 09, 2017 7:17 AM
To: Kernel Debugging Interest List
Subject: [windbg] Call to ExAllocatePoolWithTag() in my crash_dump driver
NEVER RETURNS

Hi all,

I have written my crashdump virtual miniport driver. This crashdump driver
works fine for complete, kernel, and mini dumps. However, OCASSIONALLY, the
BSOD screen hangs with dump at 0% when tested in Windows Server 2016.

When I debugged using WinDbg, it is showing that the call to
ExAllocatePoolWithTag() NEVER RETURNS. It stays there indefinitely. Please
find the below function call:

pDeviceExtension->pcmdbuf=(struct mycmdrsp
*)ExAllocatePoolWithTag(NonPagedPoolCacheAligned,pNum_bytes,‘MTAG’);

After this call, I am checking for NULL as follows:

if(pDeviceExtension->pcmdbuf == NULL)
{

}

However, since this call to ExAllocatePoolWithTag() does not returns, I am
not sure what could be the reason, and unable to get some lead to this
problem.

Please help.
Thanks in advance.


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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:</http:></http:>

Thanks for replying Don.

Any specific reason for not able to allocate at crashdump time ? I’m asking
this because the code works fine. It is only (7 out of 10 times it hangs).
My second doubt, if I’m unable to allocate memory, then this function
should have returned NULL, but this call does not even return at all.

Pardon me if my doubts seem naive as I am new to this area.

Regards,
Utkal.

On 9 March 2017 at 18:11, Don Burn wrote:

> You can’t do allocations at crash dump time, you need to have pre-allocated
> all your memory for that.
>
>
> Don Burn
> Windows Driver Consulting
> Website: http://www.windrvr.com
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> Sent: Thursday, March 09, 2017 7:17 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] Call to ExAllocatePoolWithTag() in my crash_dump driver
> NEVER RETURNS
>
> Hi all,
>
> I have written my crashdump virtual miniport driver. This crashdump driver
> works fine for complete, kernel, and mini dumps. However, OCASSIONALLY, the
> BSOD screen hangs with dump at 0% when tested in Windows Server 2016.
>
> When I debugged using WinDbg, it is showing that the call to
> ExAllocatePoolWithTag() NEVER RETURNS. It stays there indefinitely. Please
> find the below function call:
>
> pDeviceExtension->pcmdbuf=(struct mycmdrsp
> *)ExAllocatePoolWithTag(NonPagedPoolCacheAligned,pNum_bytes,‘MTAG’);
>
> After this call, I am checking for NULL as follows:
>
> if(pDeviceExtension->pcmdbuf == NULL)
> {
> …
> }
>
> However, since this call to ExAllocatePoolWithTag() does not returns, I am
> not sure what could be the reason, and unable to get some lead to this
> problem.
>
>
> Please help.
> Thanks in advance.
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> 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:
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> 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&gt;
>


*Utkal Sinha *
M.Tech (CS), NIT Rourkela
Website: www.utkalsinha.com http:</http:></http:></http:></http:>

You have a very limited set of functions available at crashdump time. Technically you are supposed to only use a limited set of Storport/Scsiport calls, plus a very limited set of the native API’s. There is no checking that the OS has crashed on kernel API calls so the results are undefined.

ExAllocatePoolWithTag relies on a lot of complex data structures, at crash dump time you cannot be sure these are consistent.

Microsoft is improving the documentation on this somewhat, especially since the added crash dump filters. Be thankful for what you can get, it used to be a lot worse.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Utkal Sinha
Sent: Thursday, March 09, 2017 7:50 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Call to ExAllocatePoolWithTag() in my crash_dump driver NEVER RETURNS

Thanks for replying Don.

Any specific reason for not able to allocate at crashdump time ? I’m asking this because the code works fine. It is only (7 out of 10 times it hangs).
My second doubt, if I’m unable to allocate memory, then this function should have returned NULL, but this call does not even return at all.

Pardon me if my doubts seem naive as I am new to this area.

Regards,
Utkal.

On 9 March 2017 at 18:11, Don Burn > wrote:

You can’t do allocations at crash dump time, you need to have pre-allocated
all your memory for that.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com mailto:xxxxx
[mailto:xxxxx@lists.osr.com mailto:xxxxx] On Behalf Of
xxxxx@gmail.com mailto:xxxxx
Sent: Thursday, March 09, 2017 7:17 AM
To: Kernel Debugging Interest List >
Subject: [windbg] Call to ExAllocatePoolWithTag() in my crash_dump driver
NEVER RETURNS

Hi all,

I have written my crashdump virtual miniport driver. This crashdump driver
works fine for complete, kernel, and mini dumps. However, OCASSIONALLY, the
BSOD screen hangs with dump at 0% when tested in Windows Server 2016.

When I debugged using WinDbg, it is showing that the call to
ExAllocatePoolWithTag() NEVER RETURNS. It stays there indefinitely. Please
find the below function call:

pDeviceExtension->pcmdbuf=(struct mycmdrsp
*)ExAllocatePoolWithTag(NonPagedPoolCacheAligned,pNum_bytes,‘MTAG’);

After this call, I am checking for NULL as follows:

if(pDeviceExtension->pcmdbuf == NULL)
{

}

However, since this call to ExAllocatePoolWithTag() does not returns, I am
not sure what could be the reason, and unable to get some lead to this
problem.

Please help.
Thanks in advance.


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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: >


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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: >



Utkal Sinha
M.Tech (CS), NIT Rourkela
Website: www.utkalsinha.com http:
— WINDBG is sponsored by OSR OSR is hiring!! Info at http://www.osr.com/careers MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Or, is it “Guaranteed” that the allocation in crashdump mode will always fail ?
Or, is it kind of undefined behavior due to which it occasionally succeeds ?

Thanks,
Utkal.

Thanks Don.

Your last reply about “limited set of functions available at crashdump time” explained me a lot. Will try to do it accordingly, and let you know my results in this forum so that my future developer friend, who gets stuck in similar situation gets some help.

Best regards,
Utkal.

xxxxx@gmail.com wrote:

Or, is it “Guaranteed” that the allocation in crashdump mode will always fail ?
Or, is it kind of undefined behavior due to which it occasionally succeeds ?

It’s not that hard to understand, is it? You get a crash dump when the
kernel detects an inconsistency somewhere. You really have no idea
where the inconsistency was. If the bug check occurred because the data
structures for the memory pool or the page tables were overwritten, then
it should be obvious that you can’t allocate any memory.

A crash dump driver needs to be almost entirely isolated from the kernel.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

So I have set the RequestedDumpBufferSize to 3*1220 in
PORT_CONFIGURATION_INFORMATION while in normal mode.
And while in dump mode, I am trying to split this buffer into 3 small
buffers by accessing the initial virtual and physical base addresses
mentioned in MEMORY_REGION structure inside the
PORT_CONFIGURATION_INFORMATION.

As I am new to this area, please suggest me the recommended or proper way
to split or map this region to 3 buffers. Or, redirect me to some useful
links.

Thanks,
Utkal.

On 9 March 2017 at 23:16, Tim Roberts wrote:

> xxxxx@gmail.com wrote:
> > Or, is it “Guaranteed” that the allocation in crashdump mode will always
> fail ?
> > Or, is it kind of undefined behavior due to which it occasionally
> succeeds ?
>
> It’s not that hard to understand, is it? You get a crash dump when the
> kernel detects an inconsistency somewhere. You really have no idea
> where the inconsistency was. If the bug check occurred because the data
> structures for the memory pool or the page tables were overwritten, then
> it should be obvious that you can’t allocate any memory.
>
> A crash dump driver needs to be almost entirely isolated from the kernel.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> 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&gt;
>


*Utkal Sinha *
M.Tech (CS), NIT Rourkela
Website: www.utkalsinha.com http:</http:></http:>

On Mar 11, 2017, at 7:36 PM, Utkal Sinha wrote:
>
> So I have set the RequestedDumpBufferSize to 3*1220 in PORT_CONFIGURATION_INFORMATION
> while in normal mode.
> And while in dump mode, I am trying to split this buffer into 3 small buffers by accessing the
> initial virtual and physical base addresses mentioned in MEMORY_REGION structure inside the
> PORT_CONFIGURATION_INFORMATION.

> As I am new to this area, please suggest me the recommended or proper way to split or map
> this region to 3 buffers. Or, redirect me to some useful links.

I have to hope you’ve had some misunderstanding making this harder than it really is, because this is a question even a first-year C programmer should be able to answer.

PUCHAR vbuf1 = pci->DumpRegion.VirtualBase;
PUCHAR vbuf2 = vbuf1 + 1220;
PUCHAR vbuf3 = vbuf2 + 1220;

ULONGLONG pbuf1 = pci->DumpRegion.PhysicalBase.QuadPart;
ULONGLONG pbuf2 = pbuf1 + 1220;
ULONGLONG pbuf3 = pbuf2 + 1220;
?
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thank you all, it is working now.
My last comment was to make sure that I am following proper steps to allocate buffers and avoid any sort of memory leaks.