Archive

Posts Tagged ‘GFlags’

How to troubleshot native memory leaks on Windows: GFlags and UMDH

August 9, 2011 8 comments

Memory issues are amongst the worst one to solve because pointing precisely the source is often difficult and painful. Memory leaks are not an exception, especially with real-world application: most of the time, programmers start to worry about it when the application outputs some “out of memory” errors. At this moment, you have to find which one, among thousands of functions and many more allocated blocks, causes the application to leak and eventually to crash.

Let’s summarize what you really need when you have a memory leak (in addition to a way to reproduce the issue):

  • You want to find which object(s) are leaking
  • You want to know why they are leaking: is there some static reference to it, or maybe they are not freed?

The process described today deals with the first one, which is often the most difficult.

Read more…

Advertisements

Who the hell killed my process?

April 17, 2011 2 comments

There is a few reasons that can make a process disappear. It can be:

  • a normal termination (you reach the end of the main function)
  • a call to ExitProcess, potentially located anywhere in your code
  • an exception walking up all through the call stack of its thread, making the process die.
Those three reasons are quite easy to debug. For the first one, just check the code logic that made the program exits. For the second one, a breakpoint put on kernel32!ExitProcess should do the trick. And of course, the third one is caught by any decent debugger because it’s what is called a Second Chance Exception, meaning that you program is about to crash.
But there is another sneaky reason: your process could have been killed by another process. Even between processes, life is hard, and as long as you have sufficient rights, killing another process is just another line of code. It can happen on production systems because of a poorly designed cleaning batch, or it can be malicious software trying to end any process that can harm it: an antivirus software, or a spying tool.
So the question is: how can you know which process killed your lovely software?

Read more…

Categories: Windows debugging tricks Tags: ,

How to debug a process as soon as it starts with WinDbg or Visual Studio 2010

Sometimes bug happens before you have the chance to attach a debugger to the faulting process. Most of the time it’s because it is launched by another process (a service, the compiler used to create a Xml serializer of a .NET software, a batch script, etc.) and you don’t have the time to get the command line with ProcessExplorer. And even if you can get it, a process may expect some context coming from its parent. And obviously, sometimes you don’t have a clue about how a process is launched, all you know is that it crashes and you need to see what’s inside before it do so.

After a few tryout to pause the process (Process Explorer is your friend) before it crashes, or some tentative to slow down your computer so you have the time to attach a debugger, you’re starting to get frustrated. Hopefully I have some solutions for you.

Read more…

How to debug a Windows service

October 14, 2010 2 comments

Maybe you thought when you read this title: “well it’s kind of easy, I just have to attach any debugger to my running service“. And you’re definitely right.

But sometimes you have to debug the very beginning of your service (just after the “Start” control), or even before, when the main() function has just started. Or you’re experiencing a bug that happens only with a specific user, or only in a context of a Windows service (could be environment variables, registry keys, etc.). Hopefully, with a few tricks, you can easily setup a debugger that will attach to a process just after its creation.

Read more…