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

  • Article

Question:

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!).

Regards,

Answer:

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.

Recommendation...

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 msnews.microsoft.com
  • 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.

//David