ExAllocatePoolWithTag and STATUS_INSUFFICIENT_RESOURCE

NTFSD
1

Until recently I did not use these two terms together. I used ExAllocatePoolWithTag and NULL rather.

In the driver code I use ExaAllocatePoolWithTag lavishly and at some dismal time my driver brings down the system.Windbg shows SYSTEM_THREAD_EXCEPTION_NOT_HANDLED as bug check code. And, unhandled exception code is 0xc000009a i.e. STATUS_INSUFFICIENT_RESOURCES.
This exception was raised by one of my call to ExAllocatePoolWithTag.
Perfectly all right! When I am extravagant with the memory usage, I am bound to face kernel’s wrath.

What bothers me here is the chasm between WDK documentation and actual system behavior. WDK does not mention that ExAllocatePoolWithTag might raise this exception; system displays the phenomenon.

Does this imply that just checking for NULL return value is not suffice when it comes to using ExAllocatePoolWithTag; I can expect some oxygen to breathe only if every call to “ExallocatePoolWithTag” appears in a try/except block ?

Please advise.

2

Its a NTDEV candidate.

>Does this imply that just checking for NULL return value is not suffice when it comes to using ExAllocatePoolWithTag; I can expect some oxygen to breathe only if every call to “ExallocatePoolWithTag” appears in a try/except block ?

We tested our driver with verifier low resource simulation but never got something like this from ExAllocatePool, we also were testing for null only but all required code was under a try _except. So its difficult to comment on who was saving us, null check or the exception handler.

could it be related to this http://support.microsoft.com/kb/142719.

3

According to the documentation, this only causes an exception if the flags
indicate you want it to throw one. This was the Win7 doc.

wrote in message news:xxxxx@ntfsd…
> Until recently I did not use these two terms together. I used
> ExAllocatePoolWithTag and NULL rather.
>
> In the driver code I use ExaAllocatePoolWithTag lavishly and at some
> dismal time my driver brings down the system.Windbg shows
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED as bug check code. And, unhandled
> exception code is 0xc000009a i.e. STATUS_INSUFFICIENT_RESOURCES.
> This exception was raised by one of my call to ExAllocatePoolWithTag.
> Perfectly all right! When I am extravagant with the memory usage, I am
> bound to face kernel’s wrath.
>
> What bothers me here is the chasm between WDK documentation and actual
> system behavior. WDK does not mention that ExAllocatePoolWithTag might
> raise this exception; system displays the phenomenon.
>
> Does this imply that just checking for NULL return value is not suffice
> when it comes to using ExAllocatePoolWithTag; I can expect some oxygen to
> breathe only if every call to “ExallocatePoolWithTag” appears in a
> try/except block ?
>
> Please advise.
>
>
>

4

>>According to the documentation, this only causes an exception if the flags indicate you want it to throw one. This was the Win7 doc.

This is the text David is referring to,

You can modify the PoolType value by using a bitwise OR with the POOL_RAISE_IF_ALLOCATION_FAILURE flag. This flag causes an exception to be raised if the request cannot be satisfied

@David

Is it really new or its like my eyes were ignoring these form years. I think i never noticed them previously with WDK 6000.

5

I think you have corrupted the paged pool due to some bug, and ExAllocate raises an exception when encountering the corrupt pool block chain.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> Until recently I did not use these two terms together. I used ExAllocatePoolWithTag and NULL rather.
>
> In the driver code I use ExaAllocatePoolWithTag lavishly and at some dismal time my driver brings down the system.Windbg shows SYSTEM_THREAD_EXCEPTION_NOT_HANDLED as bug check code. And, unhandled exception code is 0xc000009a i.e. STATUS_INSUFFICIENT_RESOURCES.
> This exception was raised by one of my call to ExAllocatePoolWithTag.
> Perfectly all right! When I am extravagant with the memory usage, I am bound to face kernel’s wrath.
>
> What bothers me here is the chasm between WDK documentation and actual system behavior. WDK does not mention that ExAllocatePoolWithTag might raise this exception; system displays the phenomenon.
>
> Does this imply that just checking for NULL return value is not suffice when it comes to using ExAllocatePoolWithTag; I can expect some oxygen to breathe only if every call to “ExallocatePoolWithTag” appears in a try/except block ?
>
> Please advise.
>
>
>

6

Typical scenarios when you get a STATUS_INSUFFICIENT_RESOURCES exception instead of a NULL return value are:

  1. You called ExAllocatePoolWithTag and the value of the PoolType parameter included the POOL_RAISE_IF_ALLOCATION_FAILURE flag.

  2. You called ExAllocatePoolWithQuotaTag and the value of the PoolType did NOT include the POOL_QUOTA_FAIL_INSTEAD_OF_RAISE flag.

Does you driver fit in any of these two scenarios?

If it doesn’t fit, I guess there was some memory corruption, as Maxim mentioned.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rediffmail.com
Sent: Wednesday, April 29, 2009 10:58 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] ExAllocatePoolWithTag and STATUS_INSUFFICIENT_RESOURCE

Until recently I did not use these two terms together. I used ExAllocatePoolWithTag and NULL rather.

In the driver code I use ExaAllocatePoolWithTag lavishly and at some dismal time my driver brings down the system.Windbg shows SYSTEM_THREAD_EXCEPTION_NOT_HANDLED as bug check code. And, unhandled exception code is 0xc000009a i.e. STATUS_INSUFFICIENT_RESOURCES.
This exception was raised by one of my call to ExAllocatePoolWithTag.
Perfectly all right! When I am extravagant with the memory usage, I am bound to face kernel’s wrath.

What bothers me here is the chasm between WDK documentation and actual system behavior. WDK does not mention that ExAllocatePoolWithTag might raise this exception; system displays the phenomenon.

Does this imply that just checking for NULL return value is not suffice when it comes to using ExAllocatePoolWithTag; I can expect some oxygen to breathe only if every call to “ExallocatePoolWithTag” appears in a try/except block ?

Please advise.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

7

Please don’t wrap code in try/except(EXCEPTION_EXECUTE_HANDLER) unless there was a good reason to wrap it.

Driver code has to be wrapped in try/except(EXCEPTION_EXECUTE_HANDLER) in scenarios such as:
a. Calling ExAllocatePoolWithQuotaTag without specifying the POOL_QUOTA_FAIL_INSTEAD_OF_RAISE flag.
b. Calling MmProbeAndLockPages.
c. Calling some other API that is documented to raise exceptions.
d. Touching a User Mode virtual address.

But wrapping other pieces of code in try/except can hide memory corruptions. For example, every once in a while I had to waste a lot of time tracking down the cause of an orphaned lock. Unfortunately it is relatively common that:

  • Someone corrupted the memory pool - e.g. there was an unexpected NULL pointer in a pool allocation.
  • That pointer was dereferenced with the lock held. We should have seen a system crash here, exposing the corruption immediately.
  • However, someone had a bogus try/except that concealed the NULL pointer dereference exception, and the current thread continued execution without ever releasing the lock.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, April 30, 2009 12:45 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] ExAllocatePoolWithTag and STATUS_INSUFFICIENT_RESOURCE

Its a NTDEV candidate.

>Does this imply that just checking for NULL return value is not suffice when it comes to using ExAllocatePoolWithTag; I can expect some oxygen to breathe only if every call to “ExallocatePoolWithTag” appears in a try/except block ?

We tested our driver with verifier low resource simulation but never got something like this from ExAllocatePool, we also were testing for null only but all required code was under a try _except. So its difficult to comment on who was saving us, null check or the exception handler.

could it be related to this http://support.microsoft.com/kb/142719.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

8

Glad you said that Dan. BSOD’s are your friend.

On Thu, Apr 30, 2009 at 11:41 AM, Daniel Mihai
wrote:

> Please don’t wrap code in try/except(EXCEPTION_EXECUTE_HANDLER) unless
> there was a good reason to wrap it.
>
> Driver code has to be wrapped in try/except(EXCEPTION_EXECUTE_HANDLER) in
> scenarios such as:
> a. Calling ExAllocatePoolWithQuotaTag without specifying the
> POOL_QUOTA_FAIL_INSTEAD_OF_RAISE flag.
> b. Calling MmProbeAndLockPages.
> c. Calling some other API that is documented to raise exceptions.
> d. Touching a User Mode virtual address.
>
> But wrapping other pieces of code in try/except can hide memory
> corruptions. For example, every once in a while I had to waste a lot of time
> tracking down the cause of an orphaned lock. Unfortunately it is relatively
> common that:
> - Someone corrupted the memory pool - e.g. there was an unexpected NULL
> pointer in a pool allocation.
> - That pointer was dereferenced with the lock held. We should have seen a
> system crash here, exposing the corruption immediately.
> - However, someone had a bogus try/except that concealed the NULL pointer
> dereference exception, and the current thread continued execution without
> ever releasing the lock.
>
> Dan
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
> Sent: Thursday, April 30, 2009 12:45 AM
> To: Windows File Systems Devs Interest List
> Subject: RE:[ntfsd] ExAllocatePoolWithTag and STATUS_INSUFFICIENT_RESOURCE
>
> Its a NTDEV candidate.
>
> >>Does this imply that just checking for NULL return value is not suffice
> when it comes to using ExAllocatePoolWithTag; I can expect some oxygen to
> breathe only if every call to “ExallocatePoolWithTag” appears in a
> try/except block ?
>
> We tested our driver with verifier low resource simulation but never got
> something like this from ExAllocatePool, we also were testing for null only
> but all required code was under a try _except. So its difficult to comment
> on who was saving us, null check or the exception handler.
>
> could it be related to this http://support.microsoft.com/kb/142719.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

9

To emphasise what Dan and Jim said BSODs are your friends.

But…

c. Calling some other API that is documented to raise exceptions.

beware that although the WDK documentation is getting better there are still lacunae. There are several functions that are not so documented but do raise exceptions.

In general all calls to Cc will need bracketing (e.g. CcSetFileSizes).

However (and this is just IMO) do *NOT* do what the example FSDs do and bracket whole huge functions - AFAIR there is a 1400 line try/finally in the create path for FASTFAT. Bracket exactly the one function that you suspect of throwing and treat the whole as a function that returns a status. For good measure slam an assert in the exception handler as well until you are completely confident.

… and beware of the dispatch handler for close - I lost a couple of days of my life to the try/except statement which surrounds it (or at least used to)

Rod

10

>1. You called ExAllocatePoolWithTag and the value of the PoolType parameter >included the >POOL_RAISE_IF_ALLOCATION_FAILURE flag.

  1. You called ExAllocatePoolWithQuotaTag and the value of the PoolType did >NOT include the >POOL_QUOTA_FAIL_INSTEAD_OF_RAISE flag. Does you >driver fit in any of these two scenarios?

Both of these are not applicable on my driver.
That leaves the possibility that my driver corrupted the paged pool.
Yes, surely it could be, but is this the only possibility? Is pool corruption the only situation when one can encounter this exception?
Or, it is just that my driver developed an insatiable appetite for memory-cookies and ate up all paged memory before it got penalized by that exception.

I have certain misgivings here, after going through all the posts, especially after touring the link posted by Aditya.
http://support.microsoft.com/kb/142719
?If the kernel allocates all of its allotted paged- pool memory, it will not be able to perform many tasks and will instead return a STATUS_INSUFFICIENT_RESOURCES (0xC000009A) message.?
^
Can I assume that they mean ?ExAllocatePool? when they say ?kernel? in the aforementioned text.

This page does not talk about paged pool limits on XP, which happens to be my target machine. However, this msdn page does-
http://msdn.microsoft.com/en-us/library/aa366778.aspx

And Mark russinovich goes at length about it here-
http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx

@Dan and Rod
Thanks for jotting down why one should not be generous in using try/except(EXCEPTION_EXECUTE_HANDLER).

11

@Dan and Rod

Thanks for explaining this. But what do you guys suggest for the customer release, i.e. for testing cycles I understand we should only enclose thing in brackets which are suppose to raise exception as this will help us in identifying any possible errors but isn’t it a good practice to have complete code in bracket if the release is going to end customer?

I remember we based our code on some minifilter sample(so not all was covered under bracket), before first major customer release after around 6 months of testing cycles, we actually covered all our code intentionally to avoid any goof-ups at client machine.

Thanks
Aditya

12

Aditya,

This is just me & YMMV. I always bracket Cc calls and treat the whole as
just another function that can fail. I also tend to put an ASSERT in the
catch block. I’ve been bitten too often by Cc/Mm, and this way I get to
have my cake (I see the oddities during test) and eat it (the customer just
sees odd failures, not blue screens).

Nothing else gets a try/except unless it it documented to throw.

As Tony said in another context, if someone installs a driver and it causes
a crash you will get the call, having the moral high ground (“the
documentation said it didn’t throw exceptions in a non fatal path”) doesn’t
cut it.

But both Dan and my real point is that you should be trying your hardest to
avoid putting things that change “state” inside a try/except and if you have
to make sure that you handle it. Dan’s example was taking an ESRESOURCE
inside a try and the catch/finally not dropping it, in my case it was a file
object which wasn’t be dereferenced.

[To loop in yet another conversation I never get bitten by ERESOURCES being
leaked because I pair them up with an APC decrement and so verifier catches
the mismatch at the system service boundary. However I have been told
firmly that this is considered a bad thing to do]

Rod

13

Thanks for your comments Rod,

With respect I want to put that I did understand the point made in the post by you and Dan. I was just trying to get a view (an experience view in fact as I already have one) on one of the approach we made in an encryption project and were assuming this as a correct approach until pointed here. In other words I was trying to found +/- of a concept which we used and already had a opinion in favor of that. My post motive was just this.

Aditya

14

Rod, thanks for pointing out the incomplete Cc documentation. Please continue to bring up any similar issues because that gives us a chance to get those docs fixed.

I have just looked at the huge try/except regions of source code in fastfat. That’s a coding style that I don’t like, but if I understand correctly, it is relatively common in FSDs. However, at least in the recent fastfat source code that I am looking at, exception handling is much more reasonable than try/except(EXCEPTION_EXECUTE_HANDLER). Fastfat is using try/except(FatExceptionFilter(IrpContext, GetExceptionInformation()), and FatExceptionFilter() is using FsRtlIsNtstatusExpected() to avoid spurious handling of unexpected exceptions. That kind of exception filter would not hide the memory corruption/NULL pointer dereference that I mentioned on Friday.

Dan

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Friday, May 01, 2009 8:06 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] RE:ExAllocatePoolWithTag and STATUS_INSUFFICIENT_RESOURCE

To emphasise what Dan and Jim said BSODs are your friends.?
?
But…
?

c. Calling some other API that is documented to raise exceptions.
?
beware that although the WDK documentation is getting better there are still lacunae.? There are several functions that are not so documented but do raise exceptions.
?
In general all calls to Cc will need bracketing (e.g. CcSetFileSizes).?
?
However (and this is just IMO) do *NOT* do what the example FSDs do and bracket whole huge functions - AFAIR there is a 1400 line try/finally in the create path for FASTFAT.? Bracket exactly the one function that you suspect of throwing and treat the whole as a function that returns a status.? For good measure slam an assert in the exception handler as well until you are completely confident.
?
… and beware of the dispatch handler for close - I lost a couple of days of my life to the try/except statement which surrounds it (or at least used to)
?
Rod

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

15

Those two are the only legitimate cases when ExAllocatePool can raise an STATUS_INSUFFICIENT_RESOURCE, as far as I know.

I guess it is possible that I am missing something though. If you can’t figure it out and you want to show me a kernel memory dump file from this exception, I might be able to help you debug it. Please send me email if you decide to follow this path.

I didn’t spend much time reading that KB article, or Mark’s blog, but at a quick look I didn’t notice any information about an ExAllocatePool exception in these articles.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rediffmail.com
Sent: Saturday, May 02, 2009 12:47 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] ExAllocatePoolWithTag and STATUS_INSUFFICIENT_RESOURCE

  1. You called ExAllocatePoolWithTag and the value of the PoolType parameter >included the >POOL_RAISE_IF_ALLOCATION_FAILURE flag.
  2. You called ExAllocatePoolWithQuotaTag and the value of the PoolType did >NOT include the >POOL_QUOTA_FAIL_INSTEAD_OF_RAISE flag. Does you >driver fit in any of these two scenarios?

Both of these are not applicable on my driver.
That leaves the possibility that my driver corrupted the paged pool.
Yes, surely it could be, but is this the only possibility? Is pool corruption the only situation when one can encounter this exception?
Or, it is just that my driver developed an insatiable appetite for memory-cookies and ate up all paged memory before it got penalized by that exception.

I have certain misgivings here, after going through all the posts, especially after touring the link posted by Aditya.
http://support.microsoft.com/kb/142719
?If the kernel allocates all of its allotted paged- pool memory, it will not be able to perform many tasks and will instead return a STATUS_INSUFFICIENT_RESOURCES (0xC000009A) message.?
^
Can I assume that they mean ?ExAllocatePool? when they say ?kernel? in the aforementioned text.

This page does not talk about paged pool limits on XP, which happens to be my target machine. However, this msdn page does-
http://msdn.microsoft.com/en-us/library/aa366778.aspx

And Mark russinovich goes at length about it here-
http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx

@Dan and Rod
Thanks for jotting down why one should not be generous in using try/except(EXCEPTION_EXECUTE_HANDLER).

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

16

My opinion is that a blue screen for an unexpected condition (such as a memory corruption, or an API that is unexpectedly raising an exception) is more useful than allowing the customer to limp through odd failures. The advantage of the blue screen is that I can get a memory dump file from it, debug and fix the problem. So I take great care in my code to avoid handling/hiding *any* unexpected exceptions. Many of my colleagues are using the same approach.

I realize that you guys might chose a different approach, for various reasons that I respect.

Rod, I usually debug memory corruptions in ntoskrnl’s data structures. Even if your driver was careful and released its own ERESOURCE from the finally block, ntoskrnl’s data structures (e.g. Pool Manager data structures) might still be corrupted and your try/except could hide that corruption. Someone will eventually have to figure out the corruption, and it’s going to be much harder to track down the corruptor if the initial crash was spuriously avoided.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Sunday, May 03, 2009 4:32 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] ExAllocatePoolWithTag and STATUS_INSUFFICIENT_RESOURCE

Aditya,

This is just me & YMMV. I always bracket Cc calls and treat the whole as
just another function that can fail. I also tend to put an ASSERT in the
catch block. I’ve been bitten too often by Cc/Mm, and this way I get to
have my cake (I see the oddities during test) and eat it (the customer just
sees odd failures, not blue screens).

Nothing else gets a try/except unless it it documented to throw.

As Tony said in another context, if someone installs a driver and it causes
a crash you will get the call, having the moral high ground (“the
documentation said it didn’t throw exceptions in a non fatal path”) doesn’t
cut it.

But both Dan and my real point is that you should be trying your hardest to
avoid putting things that change “state” inside a try/except and if you have
to make sure that you handle it. Dan’s example was taking an ESRESOURCE
inside a try and the catch/finally not dropping it, in my case it was a file
object which wasn’t be dereferenced.

[To loop in yet another conversation I never get bitten by ERESOURCES being
leaked because I pair them up with an APC decrement and so verifier catches
the mismatch at the system service boundary. However I have been told
firmly that this is considered a bad thing to do]

Rod

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

17

Please have a look at the output of analyze -v , Dan.

************************************************************************
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c000009a, The exception code that was not handled
Arg2: 80ae3c7b, The address that the exception occurred at
Arg3: edcf9954, Exception Record Address
Arg4: edcf99a4, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc000009a - Insufficient system resources exist to complete the API.

FAULTING_IP:
nt!ExAllocatePoolWithTag+31b
80ae3c7b 8b45ec mov eax,dword ptr [ebp-14h]

EXCEPTION_RECORD: edcf9954 – (.exr ffffffffedcf9954)
ExceptionAddress: 80ae3c7b (nt!ExAllocatePoolWithTag+0x0000031b)
ExceptionCode: c000009a
ExceptionFlags: 00000001
NumberParameters: 0

CONTEXT: edcf99a4 – (.cxr ffffffffedcf99a4)
eax=00000203 ebx=86bd6000 ecx=86bdb0c8 edx=00000000 esi=00000001 edi=80b0a760
eip=80ae3c7b esp=edcf9c80 ebp=edcf9ce0 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202
nt!ExAllocatePoolWithTag+0x31b:
80ae3c7b 8b45ec mov eax,dword ptr [ebp-14h] ss:0010:edcf9ccc=00000000
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x7E

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc000009a - Insufficient system resources exist to complete the API.

LAST_CONTROL_TRANSFER: from ed7f50eb to 80ae3c7b

STACK_TEXT:
edcf9ce0 ed7f50eb 00000011 00001008 6f72706e nt!ExAllocatePoolWithTag+0x31b
edcf9d30 ed7f4673 86360978 862b6710 edcf9d70 MyFSD!MyFSDWriteCPJournalBlock+0xbb
edcf9d94 ed7f4765 862b6710 00000000 862b6710 MyFSD!MyFSDWriteCPPackToDisk+0x1c3
edcf9dac 80bcb95a 862b6710 00000000 00000000 MyFSD!MyFSDCheckPointProcess+0x65
edcf9ddc 80adae82 ed7f4700 862b6710 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
MyFSD!MyFSDWriteCPJournalBlock+bb [d:\myfsd\checkpointing.c @ 967]
ed7f50eb 8945e0 mov dword ptr [ebp-20h],eax

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: MyFSD!MyFSDWriteCPJournalBlock+bb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: MyFSD

IMAGE_NAME: MyFSD.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 49f6ff54

STACK_COMMAND: .cxr 0xffffffffedcf99a4 ; kb

FAILURE_BUCKET_ID: 0x7E_MyFSD!MyFSDWriteCPJournalBlock+bb

BUCKET_ID: 0x7E_MyFSD!MyFSDWriteCPJournalBlock+bb

Followup: MachineOwner

************************************************************************

18

ah, what a baloney I made here!

Above stack frame depicts ExAllocatePoolWithTag being invoked by MyFSDWriteJournalBlock. However, it actually calls FsRtlAllocatePoolWithTag, which, in turn, is following macro-

#define FsRtlAllocatePoolWithTag(PoolType, NumberOfBytes, Tag) \
ExAllocatePoolWithTag((POOL_TYPE)((PoolType) | POOL_RAISE_IF_ALLOCATION_FAILURE), \
NumberOfBytes, \
Tag)

Thanks galore, Dan. I should have come up with this post right after your first post.