I have a .net application which I don't have source too. I'm interested in determining what files this application is accessing. I thought that a debugger would be a good way to do this. I work only in the linux world and know nothing about windows debuggers. I feel like there should be a way to do this with windbg, I know how I would go about it with gdb but not with windbg. Any help or advice is much appreciated.
If you just want to monitor file system activity for a given process then you won't find anything better than Process Monitor. It does lots more too and it's free from Sysinternals (now Microsoft).
Process Monitor is an advanced
monitoring tool for Windows that shows
real-time file system, Registry and
process/thread activity. It combines
the features of two legacy
Sysinternals utilities, Filemon and
Regmon, and adds an extensive list of
enhancements including rich and
non-destructive filtering,
comprehensive event properties such
session IDs and user names, reliable
process information, full thread
stacks with integrated symbol support
for each operation, simultaneous
logging to a file, and much more. Its
uniquely powerful features will make
Process Monitor a core utility in your
system troubleshooting and malware
hunting toolkit.
Stu is right if you just want to know what files are being accessed.
But if you want to know more about debugging .net apps, you can place break points on .net code when you have SOS.dll loaded into windbg. It's more involved than I can describe here, but you can Google windbg and SOS.DLL to find more info. Tess Ferrandez has a great blog that you may find useful, too: http://blogs.msdn.com/b/tess/
Related
I am running Windows 7 on which I want to do kernel debugging and I do not want to mess with boot loader. So I've downloaded LiveKd as suggested here and make it run and seems it is working. If I understand correct it is some kind of read only debugging. Here is mentioned that it is very limited and even breakpoint cannot be used. I would like to ask if is possible in this mode to periodically dump all the instructions that are being executed or basically all events which are happening on current OS? I would like to have some system wide strace (Linux users know) and to do some statistical analysis on this. I suppose it depends on more factors like installed debug symbols to begin able resolve addresses etc.
I'm not sure if debugger is the best tool you can use for tracing live system calls. As you've mentioned LiveKd session is quite limited and you are not allowed to place breakpoints in it (otherwise you would hang your own system). However, you still can create memory dumps using the .dump command (check windbg help: .hh .dump). Keep in mind though that getting a full dump (/f) of a running system might take a lot of time.
Moving back to the subject of your question, by using the "dump approach" you will miss many system calls as you will have only snapshots of a system at given points in time. So if you are looking for something similar to Linux strace I would recommend checking those tools:
Process Monitor (procmon) - it's a tool which will show you all I/O requests in the system, as well as operations performed on the registry or process activity events
Windows Performance Toolkit - it contains tools for collecting (WPR) and analysing (WPA) system and application tracing events. It might be a lot of events and it's really important to filter them accordingly to your needs. ETW (Event Tracing for Windows) is a huge subject and you probably will need to read some tutorials or books before you will be able to use it effectively (but it's really worth it!).
API Monitor - it's one of many (I consider it as one of the best) tracing applications - this tool will allow you to trace method calls in any of the running processes. It has a nice interface and even allows you to place breakpoints on methods you'd like to intercept.
There are many other tools which might be used for tracing on Windows, but I would start with the ones I listed above. You may also check a great book on this subject: Inside Windows Debugging. Good luck! :)
When I install a program I need to know what files were added/modified, which registry was modified. Can someone suggest a program that does this or maybe a code?
I think, this tool makes exactly what you need: http://technet.microsoft.com/en-us/sysinternals/bb896645
Process Monitor is an advanced monitoring tool for Windows that shows
real-time file system, Registry and process/thread activity. It
combines the features of two legacy Sysinternals utilities, Filemon
and Regmon, and adds an extensive list of enhancements including rich
and non-destructive filtering, comprehensive event properties such
session IDs and user names, reliable process information, full thread
stacks with integrated symbol support for each operation, simultaneous
logging to a file, and much more. Its uniquely powerful features will
make Process Monitor a core utility in your system troubleshooting and
malware hunting toolkit.
Systracer perfectly do what you want:
SysTracer is a system utility tool that can scan and analyze your
computer to find changed (added, modified or deleted) data into
registry and files.
There is both a free and a paid versions.
http://www.blueproject.ro/systracer
With the dump debugging support in .NET 4.0 we are looking into automatically (after asking the user of course :) creating minidumps of C# program crashes to upload them to our issue tracking system (so that the minidumps can assist in resolving the cause of the crash).
Everything is working fine when using the WithFullMemory minidump type. We can see both stack and heap variables. Unfortunately the (zipped) dumps are quite large even for small C# programs.
If we use the "Normal" minidump type we get a very small dump, but not even stack variable information is available in the managed debugger. In fact, anything less than WithFullMemory seems quite useless in the managed debugger. We have made a few attempts at using a MINIDUMP_CALLBACK_ROUTINE to limit the included module information to our own modules, but it seems that it has almost no effect on a managed dump but still manages to break the managed debugging?
Does anyone have any tips on how to trim the minidump while keeping it useful for managed debugging?
I use the following flags to save space will generating useful minidumps for C++ applications:
MiniDumpWithPrivateReadWriteMemory |
MiniDumpWithDataSegs |
MiniDumpWithHandleData |
MiniDumpWithFullMemoryInfo |
MiniDumpWithThreadInfo |
MiniDumpWithUnloadedModules
The flag values are specified in DbgHelp.h and would need to be marshaled into C#. The dump is further restricted by specifying a CallbackRoutine.
Just fyi, as mentioned above ClrDump looks very cool but it appears it only works with the 1.1. and 2.0 runtimes.
With all due respect, I STRONGLY encourage you to sign-up for a Microsoft WinQual account, register your applications with Microsoft.
http://www.microsoft.com/whdc/winlogo/maintain/StartWER.mspx
This will allow you to not only take advantage of Microsoft's extensive crash collection and analysis services (for free!), but will also allow you to publish fixes and patches for your applications through Windows' built-in error reporting facilties.
Further, by participating in the WinQual program, enterprises who deploy your app and who employ an in-house Windows Error Reporting system will be able to collect, report and receive patches for your app too.
Another benefit is that employing WinQual, you're one step closer to getting your app logo certified!
Every OEM & ISV I've worked with who uses WinQual saves an ENORMOUS amount of effort and expense compared to rolling their own crash collection and reporting system.
I wrote an email to author of ClrDump asking a question what MINIDUMP_TYPE parameters his tool used to create dumps in 'min' mode. I posted his answer here: What is minimum MINIDUMP_TYPE set to dump native C++ process that hosts .net component to be able to use !clrstack in windbg
ClrDump might help you out.
ClrDump is a set of tools that allow to produce small minidumps of
managed applications. In the past, it was necessary to use full dumps
(very large in size) if you needed to perform post-mortem analysis of
a .NET application. ClrDump can produce small minidumps that contain
enough information to recover the call stacks of all threads in the
application.
I was wondering if there is a less intrusive way to analyze a running, managed process in production environments.
Less intrusive meaning:
No delay of execution when attaching the debugger.
No delay of execution when getting basic stats like running threads.
In the Java world there is a such a tool part of the JDK. I was wondering if there're similar tools in the .NET world.
The tool should answer questions like:
What are the thread pool parameters? Same as "!threadpool" in Windbg.
What are the callstacks of my currently running threads (yep, you get it from the Java tool :) ).
Basic heap analysis e.g. howmany objects of type ABC.
Any ideas?
Alex
If I understand you correctly, you don't want to actually debug the program, only get some basic information. In such cases, Process Explorer may be sufficient.
As Oefe says, you can get a lot of info including the stacks of all threads from Process Explorer. Also, the .NET runtime has a number of useful performance counters, that may give you some insight. If you have special needs, your application can publish its own counters.
Here is production debugging in a non-intrusive manner using ETW and another one
It depends on what you want to debug. WinDbg is the giant hammer of Windows debugging, suitable for debugging anything from kernel extensions on up.
If you just want to debug a program, most people just use visual studio, which will attach to a running processs.
However, #oefe may have the bull by the horns here. When most people say 'debugger' they want backtraces and breakpoints and such. In Java, you need to make prior arrangements to attach that sort of debugger. Either Windbg or visual studio (-debugexe) is more convenient than that.
I'm using WinDBG occasionally to analyze problems in production environment, where VS cannot be installed. There's no doubt it's an extremely powerful tool, but using it is a bit annoying. Even though the product is frequently updated, its GUI goes back to the Win95 days or so, and its usability is accordingly. Having to fight the GUI to layout the windows the way I want, and having to remember all those textual commands, is just quite low a standard for a modern desktop application.
AFAIK, WinDBG is pretty much built on top of CDB, which is a command line debugger. Being so, it shouldn't be that hard to built a modern days GUI wrapper that will replace the existing dinosaur. Has anyone ever done that? Am I the only one having those mixed feelings toward WinDBG?
(BTW, I know I can create a dump and take it back to where I have VS, but I sometimes have to debug 64 bit processes, and I don't have a 64 bit dev machine. Sad, but true)
Consider the new WinDbg. (It's still in Preview). It also supports Time Travel Debugging.
You can install it from the Microsoft Store, or use the links here.
Here is what's new with Windbg Preview.
Have look at this if you fancy trying out a GUI to replace WinDbg.
EDIT:
Since SOS Assist is no longer available, this answer should be deleted. As this answer has been accepted, I personally cannot delete it. In that, please ignore my answer.
I guess thats too much to expect. With such a large number of commands that it has, it will not be trivial to have UI that displays everything in fancy controls. It might also make it bulkier, slower.
However it does provide you with controls that any user mode application debugger should have. It displays most frequently needed information like call stack, local variables, threads and so on in seperate windows.
But if you need more advanced debugging feature, you alwalys have the command interface.
WinDBG is pretty much it, no one has ever bothered to write their own UI for it. Even with its quirks I'm a fan because it's mostly command line driven. So, to each their own :)
Note that the VS 2011 Dev Preview basically integrates WinDBG support, so in the future VS will be the new WinDBG UI.
-scott