Can I set the Visual Studio debugger to break on thread creation?
(Note this is not the same as breaking on context switch as asked for in this other question: Can I set a breakpoint in Visual Studio (c++) to break on a thread context switch?)
I've found a way to do it. While googling I saw the opposite question:
Is it possible to break on thread exit with specific error code?
I put a breakpoint at the function RtlExitUserThread, after that I realized that all threads was creating with the function RtlUserThreadStart, so put another breakpoint to that function and that's all :)
As explained by #George, there are two functions you can break on. If you want to find out what creates the new thread you should break on thread creating WINAPI function calls such as CreateThread or _beginthread(ex). If you want to break into the start of the newly created thread (on the call stack of that thread itself) you should break into RtlUserThreadStart.
However, there are two prerequisites to be able to break into either of these:
1. Symbol downloading from Microsoft Servers needs to be enabled
For the breakpoints to work the debugger needs to know some basic symbol information of the native dlls. Make sure symbol loading from MS servers is enabled (Tools -> Options -> Debugging -> Symbols)
2. You need the actual stdcall signatures of the target functions
For some reason even with enabled export loading VS was unable to find the functions I needed to break on for me. So I went checking what the actual signatures are. This can be done by using the dumpbin cmd line tool of VS, or by running a short test on the code:
void* ptr = CreateThread;
Running this code in the debugger reveals the address and signature of the CreateThread for example which is _CreateThreadStub#24 for me (Win7 32-bit application). For RtlUserThreadStart it was ___RtlUserThreadStart#8 for me.
3. Setting the breakpoint
Now it's as easy as choosing Debug -> New Breakpoint -> Break at Function. For the function name you put either _CreateThreadStub#24 or ___RtlUserThreadStart#8 and leave the rest be.
This then triggers when a new thread is being created.
Observation
_CreateThreadStub#24 seems to cover the CreateThread, _beginthread and _beginthreadex functions.
If you know the thread is being created by the managed Thread class, then a simple solution would be to put a breakpoint on its entry (by going to the Breakpoints window, clicking New->Break at function and marking Thread.Start).
Otherwise, as Hans said, you would have to use a more complex solution like mdbg, or using a open-source implementation of CLR profiler (like SAE) and putting an "asm int 3" instruction in the ICorProfilerCallback::ThreadCreated method.
Also, if you have VS2010 Ultimate, you could just look up the Thread Created event in Intellitrace events, and possibly get the information you need from there (though this will not break when the thread is created, but rather give you some info about the stack trace/variable values at the time it was created, in retrospect).
Yes, the debugger gets a notification for it. No, the UI doesn't allow you to tell it to break on that notification. If this is for managed code then you could use the MDbg sample and modify it.
There are at least 2 potential things you could mean when you say you want to break on thread creation:
Break inside the creating thread BEFORE the new thread has been created
Break inside the NEW thread before the user-provided function is called.
For the first option, you'll want to break in CreateThread, _beginthread, or _beginthreadex.
For the second option, you'll want to break in RtlUserThreadStart or BaseThreadInitThunk to catch the new thread early in its execution before user code gets called.
Unfortunately, Visual studio won't break in those functions if you create a breakpoint with the function names I've listed above, at least not by default. The problem is that for native debugging, it doesn't load DLL exports by default, and without that, the debugger has no idea where to find the names I've provided above.
Before you start debugging, in Visual Studio go to tools, options, debugging, then expand the debugging options tree in the left pane. Then click on "native" and check "Load DLL Exports". Then you can start debugging your executable again.
After that, you should be able to create a breakpoint on any of the functions I mentioned by typing in the name. You may or may not need to specify the DLL the function is in by creating the breakpoint with the name as follows:
{,,kernel32.dll}CreateThread
or
{,,ntdll.dll}RtlUserThreadStart
I got this information by starting here:
https://blogs.msdn.microsoft.com/reiley/2011/07/26/debugging-tips-for-multi-threaded-application/
and doing some experimenting on my own. I know this is a response to an old question but I hope this saves other people some of the pain I've had when trying to debug crashes that happen immediately upon thread startup.
You can set a breakpoint at the first call to CreateThread (maybe you insert a fake call for this purpose).
When hit, change from Source Code View to Disassemly View and step into the call. Go through the ImportLib-Code and set a breakpoint. Not perfect, but it works.
Related
I am writing an Excel VSTO add-in. This add-in loads and runs unmanaged code.
In the startup code of the unmanaged dll, an invisible window for request handling is created. This function call causes a managed exception (LoaderLock) and if I remove it, everything works. I want to avoid creating an extra version just because of this. Is there a way for the unmanaged code to find out at runtime whether it is running in a managed thread? In this case, I could add a runtime check. The window is only needed in a fully unmanaged environment.
Note 1: The issue only occurs in this Excel add-in; a stand-alone managed console application using the unmanaged dll does not show this problem.
Note 2: I know that there are many things that should not be done from within DllMain. What I am doing has been working for more than a decade in managed and unmanaged environments and I want to keep code changes as small as possible.
Checking if mscoree.dll has been loaded has done the trick for me:
if (::GetModuleHandleW(L"mscoree.dll") == nullptr)
This: Checking if a WIN32 / Unmanaged DLL is loaded from a COM module on runtime and this: What does it mean when code "runs on" the .NET CLR? helped.
As exposed in the comments below, this does not tell which type of thread has loaded the dll, but only whether there is any managed component in the process. A more precise check would still be preferred. For the moment, I can live with this solution.
Is there a way to tell pyCharm that it should skip framework code? The debugger should skip all lines which are not from me.
In my case it is very easy to tell which code I want to debug and which not:
Code in virtualenv lib should be skipped
Code in virtualenv src should be debugged.
If I press F7 (Step Into) it should skip all lines which are not from my code base.
[Update May 2015: introduced in PyCharm 4.5]
There are two new features now, one of which is the one you asked for, but I mention the other one as well because it is topically very close.
From the 4.5 release notes:
Step into My Code
Stay focused on your code by telling the debugger to step only through your project code, as opposed to stepping through the library sources.
[...]
Ignore Library Files
The debugger is improved with the new 'Ignore library files' option. Use it to have the debugger stop inside your code in case the exception is raised in a library module, instead of stopping inside the library code.
[Update after learning about blackboxing libraries in debugging]
In this answer it is mentioned that you can add the modules to ignore into "the dict DONT_TRACE in /helpers/pydev/pydevd.py"
And there is an open issue on the issue tracker.
[original answer]
It is not possible to skip code like that, but you can flexibly switch between walking through the code line by line and making bigger jumps in a running debug session by simply adding another breakpoint (while debugging - break points can be changed in a running debug session) at the position after the library code you want to skip and press 'Resume Program' in the Debugger. The library code is skipped and you are back in your code.
You might also want to use conditional breakpoints to make sure that the program breaks into the debugger exactly when the program is in the state that you desire: right click on a breakpoint and enter a condition that has to evaluate to True in the context of that line.
i´m currently developing a debugger for Mono. Therefore I am using the Mono.Debugger.Soft.dll which has the VirtualMachineManager and VirtualMachine.
The question is: If I want to create a breakpoint in a simple program, how can i do this?
(E.g. Sourceodefile: Program.cs and Line: 17)
The Instance of VirtualMachine has a SetBreakpoint-Method, but this Method wants a MethodMirror. It is not clear for me how i can obtain this with knowing only the location within the sourcecode-File?
greets
Christian
What you have to do is listen for TypeLoad events. When you get a TypeLoad event, iterate over all of the MethodMirrors in the TypeMirror looking for a matching filename and line number.
If you find a match, then you can set a breakpoint on that MethodMirror at the ILOffset.
However, if the program has already started running, you may have a problem in that you may have missed the TypeLoad event for the Type that the method exists in. The solution to that is to keep a cache of all loaded TypeMirrors from the very start of debugging the program so that you can also iterate over types that have been loaded before the user tries to add said breakpoint.
You may be interested to know that a command-line debugger is already in development: https://github.com/mono/sdb
I'm learning how to use a debugger and wonder if I'm missing the obvious.
My simple script includes two functions that work OK. The main code calls them repeatedly. Is there an easy way to single-step through ONLY the calling code, while the functions and the libraries they use run at normal speed?
I'm using python 2.7 and pyscripter, but I'd imagine that people might want this in other debuggers and languages. Perhaps there's a way to mark sections of code as trusted, and single-step the rest?
With search help from Dani's comment, I found several great explanations elsewhere on Stack Overflow. My favorite, from polygenelubricants on this Eclipse question:
When debugging lines of code, here are the usual scenarios:
(Step Into) A method is about to be invoked, and you want to debug into the code of that method, so the next step is to go into that method and continue debugging step-by-step.
(Step Over) A method is about to be invoked, but you're not interested in debugging this particular invocation, so you want the debugger to execute that method completely as one entire step.
(Step Return) You're done debugging this method step-by-step, and you just want the debugger to run the entire method until it returns as one entire step.
(Resume) You want the debugger to resume "normal" execution instead of step-by-step.
(Line Breakpoint) You don't care how it got there, but if execution reaches a particular line of code, you want the debugger to temporarily pause execution there so you can decide what to do.
Eclipse has other advanced debugging features, but these are the basic
fundamentals.
I have some code which generates a large quantity of ArgumentExceptions on one particular line (which is in a different developer's code, so I can't just change it), which are then caught and handled appropriately.
I'm trying to debug ArgumentExceptions which are happening in a different section of code (and are then caught and handled, so I can't just look at unhandled exceptions).
Is there some way to ignore the ArgumentExceptions originating from that particular other line of code, while still breaking on ArgumentExceptions which are thrown elsewhere?
You might be able to do this, but it depends on how the code you want to debug is located relative to the other developer's code, and whether or not you can modify (but not commit your changes) to his code.
The first thing you'll want to do is, at least temporarily, go to menu Tools -> Options -> Debugging in Visual Studio, and tick the "Just My Code" box. I assume this is available even in Express editions, but it may not be, and if it's not available for you I'm afraid the rest of what I have to say probably won't help.
Anyway, once you have that ticked, you will no longer see break-on-throw notifications for code that isn't "yours." This means code that is from an assembly not in your .sln, or code marked with the [DebuggerNonUserCode] attribute from System.Diagnostics. What I usually do then is temporarily decorate the offending methods with [DebuggerNonUserCode] until I'm done debugging what I need to debug, and then revert those changes before checking in to souce control.
It's not as elegant as I'd like (I'd love a "never break on throws from this site again" checkbox in the exception assistant), but it's better than nothing.
I believe there may be other debugger settings that could interact with how "Just My Code" works, so if this doesn't work for you let me know and I'll try to get a more accurate picture of what my settings look like when I do this.
If you are talking about the "Break On Throw" exception feature then no there is not. It is strictly a type based feature only and does not have any way to control for what section of the code throws the exception.
Your best bet is to just place breakpoints on all of the lines which throw or temporarily suspend throwing an exception from the one place that you care about.
If you know how you are calling it, I would set the break point in your code and then step into (F11) from there. You could also smack the programmer until they fix their code, which would have the effect of making you feel better (unless you are a pacifist) and maybe they won't have so many ArgumentExceptions in their code (which would probably make you feel better even if you are a pacifist).
Sounds like using exceptions as flow control. If the one you're trying to debug occurs later in the program, you can try to attach the debugger later, or you can wait until after the program is running to turn on breaking when an ArgumentException is thrown.
Try to limit the scope as well - if the exception you're interested in derives from but is not exactly ArgumentException, break on that one instead.
Tell the other developer to fix his code.
Edit: In .NET 4, you can attach a handler to the AppDomain.FirstChanceException event, filter out non-ArgumentException excepitons and filter out the bad one based on the call stack.
The links in the comments are great.
i think Conditional Breakpoints are what you're looking for here. You can do this by right clicking your breakpoint and clicking the Condition... menu item.