Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Call to ExAllocatePoolWithTag() in my crash_dump driver NEVER RETURNS

Utkal_SinhaUtkal_Sinha Member Posts: 14
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.

Comments

  • Don_BurnDon_Burn Member - All Emails Posts: 1,710
    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: [email protected]
    [mailto:[email protected]] On Behalf Of
    [email protected]
    Sent: Thursday, March 09, 2017 7:17 AM
    To: Kernel Debugging Interest List <[email protected]>
    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://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer&gt;
  • Utkal_SinhaUtkal_Sinha Member Posts: 14
    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: [email protected]
    > [mailto:[email protected]] On Behalf Of
    > [email protected]
    > 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
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    >
    >
    >
    > ---
    > 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://www.osronline.com/page.cfm?name=ListServer&gt;
    >



    --
    *Utkal Sinha *
    M.Tech (CS), NIT Rourkela
    Website: *www.utkalsinha.com*
  • Don_BurnDon_Burn Member - All Emails Posts: 1,710
    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: [email protected] [mailto:[email protected]] On Behalf Of Utkal Sinha
    Sent: Thursday, March 09, 2017 7:50 AM
    To: Kernel Debugging Interest List <[email protected]>
    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 <[email protected] 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: [email protected] <mailto:[email protected]>
    [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of
    [email protected] <mailto:[email protected]>
    Sent: Thursday, March 09, 2017 7:17 AM
    To: Kernel Debugging Interest List <[email protected]
    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://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer


    ---
    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://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer





    --

    Utkal Sinha
    M.Tech (CS), NIT Rourkela
    Website: www.utkalsinha.com <http://www.utkalsinha.com&gt;
    --- 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
  • Utkal_SinhaUtkal_Sinha Member Posts: 14
    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.
  • Utkal_SinhaUtkal_Sinha Member Posts: 14
    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.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,600
    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Utkal_SinhaUtkal_Sinha Member Posts: 14
    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:

    > [email protected]ail.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, [email protected]
    > 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
    >
    > 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*
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,600
    On Mar 11, 2017, at 7:36 PM, Utkal Sinha <[email protected]> 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Utkal_SinhaUtkal_Sinha Member Posts: 14
    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.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Internals & Software Drivers 30 Nov 2020 LIVE ONLINE
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Developing Minifilters Early 2021 LIVE ONLINE