Three threads in Windows

Question

I wrote a little program which just shows a dialog. Basically an ASM Hello World. When the dialog is displayed and I break in WinDBG, I can see three threads even though the application doesn't use any threads at all.

I was not aware that there is something like default threads applied to a process, or is this because of WinDBG?

The Process/Thread window shows

 000:13d4:MyApp.exe
    000:d14
    001:11bc
    002:50c

If I put a memory access breakpoint and the process would have multiple threads, do I have to specify in which thread this should be triggered. I think this shouldn't matter right? So if an address is accessed by any thread, the breakpoint should trigger regardless.

udate

So I took now a closer look (the handle numbers have changed, but the IDs are relevant anyway). I'm Running Windows 7-32bit-x86 if that helps.

000: refers to my original process, but this was already known.

001: Stacktrace when I break looks like this (some thread snychronization required by WinDBG?):

ntdll!KiFastSystemCallRet
kernel32!WaitForMultipleObjectsEx+0x8e
kernel32!WaitForMultipleObjects+0x18
msiltcfg!RestartMsi+0x32e
kernel32!BaseThreadInitThunk+0x12
ntdll!RtlInitializeExceptionChain+0xef
ntdll!RtlInitializeExceptionChain+0xc2

It seems that this thread belongs to some msiltcfg.dll which would be a Windows 7 DLL, but why does it cread threads in my process?

002: So this would probably be the WinDBG thread which Akira32 refers to in his answer, right? (why does WinDBG need a thread of his own?).

ntdll!DbgBreakPoint
kernel32!BaseThreadInitThunk+0x12
ntdll!RtlInitializeExceptionChain+0xef
ntdll!RtlInitializeExceptionChain+0xc2

Answer 1

By your description:

Yes, your program should have only one thread running, without debuger. You can check this on task manager. However when you attach to windbg it will create a thread on break. The third thread that you mention, i really dont have a clue. Maybe a injected dll running code...

But you can try to find out by opening the windows "call stack" on winbgd. (and selecting each thread, on thread window)

• You will see you code's thread, with last function call on top.
• Windbg thread , probably with the function ntdll!DbgBreakPoint on top.
• The third one, see where it stops and what dll the code belongs on dissambly window.

You are right. You just need to set a breakpoint any thread will trigger on acess :).

Lets us know what you find out :).

Hope I have helped!

UPDATE

002:

The windbg creates that thread every time you pause the attached process execution. It makes sense because the windbg needs a breakpoint to stop the execution, since he dont know where to patch a normal breakpoint on the code, to break immediately. He creates a thread to call dbgbreakpoint and break.

If you continue the execution, the windbg's thread will terminate. This is a normal behavior of the debuggers, not only windbg.

001:

The msiltcfg.dll has functions to handle MSI installers. "Windows Installer Configuration API Stub" Its strange,for me, that the process has this dll loaded. By the stack call you show, its waiting for something. A thread, mutex event, etc... This thread has nothing to do with windbg. Something has loaded that dll on your process and created the thread. Almost for sure it is a operating system process.

One thing you can do is check if other processes (calc.exe or notpad.exe, simple ones) got the same thread or the same dll loaded. Some programs/OS can load dll's on abritary processes or even all and run code (using the WIN32 API function CreateRemoteThread). This is a normal behavior done by malware too :).

One thing you have for sure is that your program has only created one thread. And in a normal situation it should not have more than one.

I tested a program like your to be sure, and just got a thread.