CODEWITHSUNDEEP
windbgcallstack
Thomas Weller
Thomas Weller

Reputation: 59303

Expected LdrDoDebuggerBreak(), got NtWaitForWorkViaWorkerFactory()

During a debugging workshop, one of the participants could not follow an example.

When running an executable under WinDbg 10.0.15603.137 on his Windows 10 machine, the debugger was breaking the first time at NtWaitForWorkViaWorkerFactory() instead of the initial breakpoint in LdrDoDebuggerBreak().

When trying to run the executable with g, it says that there's no debugee to run. What could the problem have been?

Here's what it looked like:

Screenshot

The source code of the application is trivial:

#include "stdafx.h"
#include <exception>

int _tmain(int /*argc*/, _TCHAR* /*argv*/[])
{
    throw std::exception();
}

Note: I'll hardly be able to provide additional information, since I have no more access to the customer's PC and it doesn't happen on mine.

Upvotes: 1

Views: 1756

Answers (1)

conio
conio

Reputation: 3718

It's not possible to say for sure what the problem was, but we can say what the problem could have been. Luckily that's what you asked.

I can't assign exact probabilities to this, but it's quite likely that an implicitly linked DLL failed loading. That's the major thing that happens before the initial breakpoint1.

Why did a DLL failed to load? Maybe some kind of resource problem, but - especially assuming you tried running a "fresh" machine after a restart - somewhat more likely is an extra DLL being loaded on the problematic machine. Maybe an AVRF DLL, maybe an AppInit DLL, maybe one of a hundred other ways to inject DLLs into unknowing and unwilling processes2.

As I said in my comment, the way to find out for sure would have been having WinDBG break on process creation rather than on the initial breakpoint, and start debugging from there.

The way to do this is to start NTSD/CDB with -xe cpr, setting this in WinDBG's Event Filters window (accessible through the Debug menu), or using sxe cpr and .restart in WinDBG, assuming you started the process in WinDBG (rather than attached to it), which is the best easiets and best in my opinion, but that's a matter of taste.

1 I think TLS callbacks for the main modules are also executed before the initial breakpoint, but what are the chances someone messes with the project configuration or the CRT LIBs to add a problematic TLS callback? (TLS callbacks of the implicitly linked DLLs are included in "DLL loading".)

2 But again, the more nefarious and clever tricks are less common and thus less likely.

Upvotes: 2

Related Questions