Dump-debugging in DILE
I have spent the last few weeks on trying to get dump debugging working in DILE. At last, I have something that is working quite well. However, I have to warn everyone who wants to try the latest weekly build: I had to modify quite a lot of things (especially in the UI) and as a result I might have broken features that affect "live" debugging as well. So, I strongly recommend using the latest build really only for experimenting.
Enough of excuses. Here is what you get if you give the latest version a try.
Save memory dump
If you click on the File menu then you will see that there's a new item called "Save memory dump". This feature allows you to dump the memory of any (managed or unmanaged) process. Under the hood it's really just a call to a Win32 function to create the memory dump file.
Usage:
1. Click File -> Save memory dump...
1. Click File -> Save memory dump...
2. Enter the Id of the target process or select it using the Browse... button.
3. Select a dump type. You can find detailed description of what these flags mean in MSDN. In most cases, leaving the default selection is perfectly fine.
4. Select the location where the memory dump file will be saved.
5. Click Save. You're done.
Rules:
- You can dump the memory of both managed and unmanaged processes.
- The target process doesn't have to be paused or being debugged. (although taking a memory dump of a process that is running doesn't sound very useful)
- The result memory dump file is completely standard. You can load it in VS2010, WinDbg, DILE or any other debugger.
Load memory dump
This is the really interesting bit. Once you have a dump file, you can copy it to any machine, load it in DILE and check the status of the target process as it was when you made the dump. DILE is using the same API as VS2010 so you get the same features (more or less).
Usage:
1. Click File -> Load memory dump...
2. Select your dump file and click Open.
3. At this point DILE switches into a state that is very similar to what you get when you pause a live process.
Rules:
- Only .NET 4.0 target processes are supported.
- You can see threads, modules, call stack, local variables, arguments and current exception. You can inspect variables using the Object Viewer, switch between threads and frames in the call stack and so on. So you get all the usual features.
- Only .NET 4.0 target processes are supported.
- You can see threads, modules, call stack, local variables, arguments and current exception. You can inspect variables using the Object Viewer, switch between threads and frames in the call stack and so on. So you get all the usual features.
- Obviously, you can't step in the code or run the process as there's no live process.
- For now, assemblies are loaded from your hard disk and not from the memory dump. Therefore if an assembly is not exactly at the same location as it was on the original computer then you will have to help DILE and load it manually. (I'll try to fix this later.)
- For now, assemblies are loaded from your hard disk and not from the memory dump. Therefore if an assembly is not exactly at the same location as it was on the original computer then you will have to help DILE and load it manually. (I'll try to fix this later.)
- Unfortunately you can't evaluate method calls.
The latter is quite a serious limitation and I know VS2010 supports it. I think, VS uses a so called "IL interpreter" but I couldn't find any information about it. I'm afraid it's not a proper public API but rather a feature in VS2010 that is not exposed to anyone else. I've already asked about it in an MS forum and currently my question is assigned to Jon Langdon (PM of the debugger team) but I haven't received any reply yet. So, please vote on my thread, perhaps it will help me to get an answer faster. :)
Anyway, that's what I have for now. Have fun with DILE and dump-debugging. And as always, please let me know if you find any bug related to memory dump or live debugging. Or anything else. :)
Labels: DILE, dump debugging
0 Comments:
Post a Comment
<< Home