Resolving nt! ?? ::FNODOBFM::`string’+0x32c3b In Call Stacks

The nt! ?? ::FNODOBFM::`string’+0x32c3b function name strings are a common problem when examining call stacks with WinDbg, and aren’t a result of any symbol misconfiguration which is deemed the common cause. The problem lies with optimisation strategies added by Microsoft. The common problem occurs because of the Basic Block Tools, which is used to produce greater working set management for Win32 applications. BBT will additionally edit the public symbol files (.PDB). This problem will not affect private symbols.

We can dump the call stack with the knL command, and then examine the return addresses of the said functions.

knLUsing the .fnent command on the return address, we’ll  find the start address of the function to apply to the nt module.

.fnentNow applying this address to the nt module, and then using the ln command will find the closest  function names related to the supplied address.

lnThe function name associated with the address was nt!MiDeleteVirtualAddresses, which fits perfectly with the context of our call stack.

Now, we’ll apply the same method to the other function name which hasn’t been properly parsed by WinDbg.

.fnent #2Again, we use the ln command with nt+offset, which gives:

ln #2However, there doesn’t seem to be an exact match to the appropriate function, and can therefore be rather ambiguous to which is the correct function. To resolve this problem, and verify which function is correct, then we can use the !stack -p extension which is part of the custom CMKD.dll:

!stack -pThe correct function is the nt!MiLocateWsle, which again fits with the context of our call stack. From this, I rather that the Memory Manager is searching through the Working Set List Entries which belong to that particular address space, and then removing the corresponding entries.

Understanding the .fnent Command:

This section is largely based upon some great information I read in a NT Debugging post (see end of this section), which goes beyond the scope of the context of my initial post, and thus is the reason why I wrote this section to begin with.

Since x64 stack conventions do not use a Stack Base Pointer (rbp/ebp), then the debugger will unwind the stack of the module using the metadata stored within the binary due to the linker. The .fnent command should also be able to see which functions are using FPO on x86 platforms.

The UnwindInfoAddress is combined with the base module address to produce the UnwindInfo at address, giving the following output:

.fnent
The lmnm command will show the Begin address for the nt module:

lmnm ntThe operation section shows the assembly instructions for the function we are examining, we can use the u command with the nt!MiDeleteVirtualAddresses to support this:

uFor more information about the .fnent command, I suggest reading this post: x64 Manual Stack Reconstruction and Stack Walking

References:

Microsoft Binary Technologies and Debugging

Debugging a Network Connectivity Issue – TrackNblOwner to the Rescue

 

 

 

Advertisements

About 0x14c

I'm a Computer Science student and writer. My primary interests are Graph Theory, Number Theory, Programming Language Theory, Logic and Windows Debugging.
This entry was posted in Computer Science, Debugging, WinDbg. Bookmark the permalink.

One Response to Resolving nt! ?? ::FNODOBFM::`string’+0x32c3b In Call Stacks

  1. blueelvisrocks says:

    Reblogged this on OMG Debugging!!! and commented:
    Credits – Harry Miller (XBlueRobot)

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s