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:
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. ;-)
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?
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:
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:
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.