HOWTO: Obtain support if DebugDiag reports ntdll.dll is responsible


Hi David,

Thanks for the blog / posts... I have installed the DebugDiag from MS Betas, and have heaps of reports saying...

Please follow up with the vendor Microsoft Corporation for C:\WINDOWS\system32\ntdll.dll

and wonder if I can shortcut that route, by asking for your assistance directly?...

(Im not even sure how to go about contacting MS about this!).



DebugDiag is far from perfect when it comes to diagnosing stacks and assigning responsibility, and this sounds like one of those cases. This is because:

  • Microsoft provides a lot of common infrastructure code in DLL libraries that is called by other user's code.
  • When called incorrectly, this infrastructure code can crash and be at the top of the stack.
  • DebugDiag does very simple stack analysis and tends to point at the code at the top of the stack as the culprit and vendor to follow up with.
  • However, the real culprit in these cases is the code CALLING the infrastructure code and causing the crash.

For example, memcpy is a function provided by Microsoft, and it is well known that when you call it with a NULL pointer, it will crash. Now, some user's code can have a bug that causes NULL to be passed to memcpy, causing a crash that is now caught by DebugDiag. In this case, memcpy will be at the top of the stack and DebugDiag's simple stack analysis can identify Microsoft as the vendor to follow up with, but the real bug is the code that passes NULL to memcpy.

Thus, can you report the actual stacks that are resulting in DebugDiag identifying ntdll.dll as the problem? It will help in identifying the real culprit. When you see many things pointing at ntdll.dll as the "problem", ntdll.dll is usually the victim... because if it was the real problem, your machine would be probably be crashing a lot faster and a lot more since ntdll.dll is used everywhere. 😉

Regarding Support

Actually, the most direct route to resolving your issue is to contact Microsoft PSS with the DebugDiag logs and dump files. Yes, they will ask for your credit card to charge the support call, but they have to do that to prevent them from being front-line support for every software program running on Windows (clearly outside the scope of their responsibility). Of course, if the issue ends up being caused by Microsoft code, the charge will be refunded as it is a bug-report; it is only fair.

Thus, it is not a good idea nor a shortcut to ask me for "vendor followup" because it is really the long-route. Why?

  • Microsoft PSS has paid support professionals whose job is to help you resolve your issues at all times. They field support calls, gather up incidents, troubleshoot them, and then drive them to resolution by either:

    • Locating an existing patch
    • Finding a work-around (if it exists) that does not require a patch
    • Determining the reason for a "by-design" or "won't-fix" behavior
    • Entering a bug that results in code change by the product's servicing team to produce a patch

  • I am in the product design group, which means that I design, develop, and test products like IIS. Specifically, I am not in product support.
  • Now, I also happen to volunteer my personal time to write about various topics of interest and help others with their questions involving IIS. I enjoy helping people understand IIS better by providing synthesized information that is often outside the scope of product documentation. So, I informally perform various aspects of product evangelism/consulting/support...

So, please accept my apologies, but asking for me to provide "vendor followup" is really asking me to perform a product support role which I am not trained to do. To pursue this route would likely result in one of the following outcomes:

  1. Your issue suddenly becomes my issue to resolve.
  2. I become the middleman in transmitting information between You and Product Support.

I hope you agree that neither are really shortcuts nor do they best utilize everyone's time and skills.


In this case, I suggest that you first post all of the stack traces that DebugDiag claims ntdll.dll is response to someone who can quickly diagnose and give a suggestion, either:

  • Blog Comment
  • Configure your Newsgroup Reader (like Outlook Express) and post to microsoft.public.inetserver.iis newsgroup on the NNTP Server at
  • Web based Newsgroup reader

Once the actual culprit is identified, then we can determine the vendor that is actually responsible. If it is Microsoft, then you should directly contact Microsoft PSS for product support.


Comments (1)

  1. greg says:

    First, I want to mention that I think the error started occurring. after a patch from MS.  I am not certain though.  My application ran fine for the longest time.   There seems to be a lot of ‘bad blood’ between Microsoft and the open source community and a fix for this from Microsoft may help with the problem.  

    I am inclined to believe that the ntdll error is widespread across many application.  If I am correct, it may be that programmers are expecting certain freedoms in some directories that is the program no longer has access to.  Here is a copy of my post from a news group that is addressing my ntdll error.  I am hoping that a solution can be found before the next release.

    ********** original post ********************************************************

    I get the same thing.  So I checked my event logs.  I get 0xc0000005 error,

    To figure out what this is, you  drop the ‘c’ and plug it into net helpmsg.

    This is what I got

    C:Usersthisisme>net helpmsg 5

    Access is denied.

    So for weeks I tried to think of what it is trying to access.  I kept thinking that

    Vista updated itself and caused the problem with a new version.  I think this is

    partially correct as it did not happen till a while after I installed 2.6.6

    Finally, it hit me.   Vista gives you grief when you access some parts

    of the c:documents and settings folder.  So I right-clicked on the

    gimp-2.6.exe file and said run as administrator.

    This worked moments ago so I am unsure as to the permanency of

    the work around.  I am posting in the hopes that the developers will

    see this and correct it on their end

Skip to main content