x64 crash dump debugging

Hello all,

A novice debugging question, any advice will be appreciated:

I’m currently debugging a crash dump from a Win7 x64 machine on which our TDI filter driver has caused a NO_MORE_IRP_STACK_LOCATIONS bug check.

I’ve got symbols loaded successfully etc so I know which line of code and where in the call stack the problem is occurring. I’ve also been able to view the device stack to see which devices we are sitting on top of. Unfortunately I can’t view all of the local variables and I need to in order to reason about how exactly the problem has occurred and whether or not I should believe the output of the !irp command (currently shows ‘too many stack locations to be believed’ error).

Can anyone provide any hints as to why not all of a function’s local variables are visible in the ‘locals’ window? My current thought is that either the stack has been corrupted or some of the values are actually stored in registers due to compiler optimisations. When I try to view the registers though I get ‘registers are not yet known’.

p.s I already know that care has to be taken to create IRPs with the correct number of stack locations - this is an internally allocated IRP that is causing the BSOD. This driver is running on tens of thousands of machines with no issue and it seems to be this particular customer’s environment that is exposing or causing our driver’s issues.

Thanks in advance for any help.

Ishan

If I were you, I would not even bother about locals, which can be optimized away by the compiler.

I would just bump the IRP stack location count in IoAllocateIrp by, say, 2, and immediately deliver to this customer.

The next release code should query the filters (which are nearly surely present, and you can look at them) on the TDI devices, and/or use a registry value for stack location bump.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hello all,
>
> A novice debugging question, any advice will be appreciated:
>
> I’m currently debugging a crash dump from a Win7 x64 machine on which our TDI filter driver has caused a NO_MORE_IRP_STACK_LOCATIONS bug check.
>
> I’ve got symbols loaded successfully etc so I know which line of code and where in the call stack the problem is occurring. I’ve also been able to view the device stack to see which devices we are sitting on top of. Unfortunately I can’t view all of the local variables and I need to in order to reason about how exactly the problem has occurred and whether or not I should believe the output of the !irp command (currently shows ‘too many stack locations to be believed’ error).
>
> Can anyone provide any hints as to why not all of a function’s local variables are visible in the ‘locals’ window? My current thought is that either the stack has been corrupted or some of the values are actually stored in registers due to compiler optimisations. When I try to view the registers though I get ‘registers are not yet known’.
>
> p.s I already know that care has to be taken to create IRPs with the correct number of stack locations - this is an internally allocated IRP that is causing the BSOD. This driver is running on tens of thousands of machines with no issue and it seems to be this particular customer’s environment that is exposing or causing our driver’s issues.
>
> Thanks in advance for any help.
>
> Ishan
>

>I would just bump the IRP stack location count in IoAllocateIrp by, say, 2,

and immediately deliver to this customer.

Thanks for your advice. I had considered blindly increasing the stack location count but thought it was a bit of a hack. I guess if it solves the problem and doesn’t create any others then it is good enough, I’ll try it.

Regarding querying the filters, should this really be necessary given that IoAttachDevice sets the stack size for our device and we use this value + 1 when allocating the IRP?

I’ve also found out that there is another TDI driver (I won’t say who the vendor is for diplomacy’s sake) below us in the stack and uninstalling this driver makes the problem go away…

> I’ve also found out that there is another TDI driver (I won’t say who the vendor is for diplomacy’s

sake) below us in the stack and uninstalling this driver makes the problem go away…

Exactly, so write the check for this driver name, and, if it is present, bump the stack location count.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

If you get loaded after other TDI clients, netbt for example, the TDI
client will have set its stack count without considering you. You need
to make sure that you load before these clients. There is a registry
entry that will increase the default netbt stack count. This has all
been discussed here in the past.

Bill Wandel

On 2014-12-11 09:22, xxxxx@baesystemsdetica.com wrote:

> I would just bump the IRP stack location count in IoAllocateIrp by, say, 2, and immediately deliver to this customer.

Thanks for your advice. I had considered blindly increasing the stack location count but thought it was a bit of a hack. I guess if it solves the problem and doesn’t create any others then it is good enough, I’ll try it.

Regarding querying the filters, should this really be necessary given that IoAttachDevice sets the stack size for our device and we use this value + 1 when allocating the IRP?

I’ve also found out that there is another TDI driver (I won’t say who the vendor is for diplomacy’s sake) below us in the stack and uninstalling this driver makes the problem go away…


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev [1]

OSR is HIRING!! See http://www.osr.com/careers [2]

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars [3]

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

Links:

[1] http://www.osronline.com/showlists.cfm?list=ntdev
[2] http://www.osr.com/careers
[3] http://www.osr.com/seminars
[4] http://www.osronline.com/page.cfm?name=ListServer

> If you get loaded after other TDI clients, netbt for example, the TDI

client will have set its stack count without considering you. You need
to make sure that you load before these clients. There is a registry
entry that will increase the default netbt stack count. This has all
been discussed here in the past.

Thanks for the response Bill. However, unless I’m really misunderstanding TDI, load order with respect to TDI clients isn’t relevant here as this bug check relates to an IRP allocated by our filter driver with a stack size based on the filter devices already attached below us. This is not an IRP from a TDI client that has resulted in a bug check when our driver or any of the filters below us has tried to process it.

Are you allocating you IRP before the other driver in the stack gets
loaded?

Bill

On 2014-12-11 12:30, xxxxx@baesystemsdetica.com wrote:

> If you get loaded after other TDI clients, netbt for example, the TDI client will have set its stack count without considering you. You need to make sure that you load before these clients. There is a registry entry that will increase the default netbt stack count. This has all been discussed here in the past.

Thanks for the response Bill. However, unless I’m really misunderstanding TDI, load order with respect to TDI clients isn’t relevant here as this bug check relates to an IRP allocated by our filter driver with a stack size based on the filter devices already attached below us. This is not an IRP from a TDI client that has resulted in a bug check when our driver or any of the filters below us has tried to process it.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev [1]

OSR is HIRING!! See http://www.osr.com/careers [2]

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars [3]

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

Links:

[1] http://www.osronline.com/showlists.cfm?list=ntdev
[2] http://www.osr.com/careers
[3] http://www.osr.com/seminars
[4] http://www.osronline.com/page.cfm?name=ListServer

> Are you allocating you IRP before the other driver in the stack gets

loaded?

No, definitely after.

Also, another question just out of interest:

If I were you, I would not even bother about locals, which can be optimized away
by the compiler.

Where do local variables go in this case? If you did need to find the value of a local variable which was subject to a compiler optimisation how would you go about doing this?

xxxxx@baesystemsdetica.com wrote:

Also, another question just out of interest:

> If I were you, I would not even bother about locals, which can be optimized away
> by the compiler.
Where do local variables go in this case?

In registers. Unless the compiler needs to call an external function,
there’s no reason for local variables to live in memory at all.

If you did need to find the value of a local variable which was subject to a compiler optimisation how would you go about doing this?

You would have to follow the disassembly and see where it went. In many
cases, unless you’re tracing the code step by step, you simply cannot
determine the value of some local variables.


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

> In many cases, unless you’re tracing the code step by step, you simply cannot determine the value > of some local variables.

Fair enough, thanks for the explanation.

> Where do local variables go in this case? If you did need to find the value of a local variable which

was subject to a compiler optimisation how would you go about doing this?

Switch optimization off. No other ways.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com