would Intel(R) VTune(TM) Thread profiler be able to tell if threads synchronization was successful? I'm never profiled any application, where do i start?
What exactly are you trying to profile or measure?
If you are trying to protect a critical resource from being accessed by 2 or more threads at the same time, then use a synchronization primitive such as a mutex/critical section/slim reader-writer locks and surround the writes to the critical resource with these primitives.
If you are trying to figure out if there is any lock contention, then I believe the profilers out there will surely be able to help you out. I've never used the Intrl profiler myself, so I can't say how well it works. The new tools in VS2010 (http://code.msdn.microsoft.com/VS2010ppa) are a great way to figure out the problems in your code if your project is VS based.
I can probably help out a little more if you provide more details.
Related
Currently, I am searching for a solution that would allow me to monitor a .NET Windows Service Application, in the production environment, and collect memory dumps. I'd like to collect them based on some specific thresholds, at will and on application crashes. I am aware of various methods to achieve this, such as:
DebugDiag
Procdump
Through WER
ADPlus
WinDbg etc.
Some of the methods facilitate the collection during a crash, such as option #3, while others can trigger based on performance counters, such as #1 and #2. Any non-invasive debugger can help me achieve the collection, but I am not sure what's the performance impact of having one attached. For example, if I use Procdump with the -e switch to collect memory dumps on unhandled exceptions, what would be the overhead for the monitored application? Bear in mind that I am referring to a production environment.
I'd be grateful if I you could point me a source or method that explains the performance impact of attaching a non-invasive debugger for memory dump collection. Ideally, that'd be a quantitative measure, although it exceeds my expectations.
P.S: I am not referring to the time needed for the memory dump to be written in the disk, where the application is completely frozen. That's another thing.
I am trying to implement some basic anti debugging functionality in my application. One area that I wanted to focus on in particular, is attempting to prevent people from easily taking a usable memory dump from my application. I read the article at:
http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx
and that gave me a lot of tips for how to detect if a debugger is present, as well as some information on how I might prevent memory dumps. But the author notes that one should be careful about using these techniques, such as removing the executable header in memory. He mentions that there might be times when the OS or other programs may want to use this information, but I cannot see for what purpose.
Has anyone got some other tips as to how I could stop reverse engineers from dumping my program?
I am on Windows.
Kind regards,
Philip Bennefall
There is no reasonable way to prevent someone from capturing a memory dump of your process. For example, I could attach a kernel debugger to the system, break all execution, and extract your process' dump from the debugger. Therefore, I would focus on making analysis more difficult.
Here are some ideas:
Obfuscate and encrypt your executable code. Decrypt in-memory only, and do not keep decrypted code around for longer than you need it.
Do not store sensitive information in memory for longer than necessary. Use RtlZeroMemory or a similar API to clear out buffers that you are no longer using. This also applies to the stack (local variables and parameters).
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 have a crash dump of an application that is supposedly leaking GDI. The app is running on XP and I have no problems loading it into WinDbg to look at it. Previously we have use the Gdikdx.dll extension to look at Gdi information but this extension is not supported on XP or Vista.
Does anyone have any pointers for finding GDI object usage in WinDbg.
Alternatively, I do have access to the failing program (and its stress testing suite) so I can reproduce on a running system if you know of any 'live' debugging tools for XP and Vista (or Windows 2000 though this is not our target).
I've spent the last week working on a GDI leak finder tool. We also perform regular stress testing and it never lasted longer than a day's worth w/o stopping due to user/gdi object handle overconsumption.
My attempts have been pretty successful as far as I can tell. Of course, I spent some time beforehand looking for an alternative and quicker solution. It is worth mentioning, I had some previous semi-lucky experience with the GDILeaks tool from msdn article mentioned above. Not to mention that i had to solve a few problems prior to putting it to work and this time it just didn't give me what and how i wanted it. The downside of their approach is the heavyweight debugger interface (it slows down the researched target by orders of magnitude which I found unacceptable). Another downside is that it did not work all the time - on some runs I simply could not get it to report/compute anything! Its complexity (judging by the amount of code) was another scare-away factor. I'm not a big fan of GUIs, as it is my belief that I'm more productive with no windows at all ;o). I also found it hard to make it find and use my symbols.
One more tool I used before setting on to write my own, was the leakbrowser.
Anyways, I finally settled on an iterative approach to achieve following goals:
minor performance penalties
implementation simplicity
non-invasiveness (used for multiple products)
relying on as much available as possible
I used detours (non-commercial use) for core functionality (it is an injectible DLL). Put Javascript to use for automatic code generation (15K script to gen 100K source code - no way I code this manually and no C preprocessor involved!) plus a windbg extension for data analysis and snapshot/diff support.
To tell the long story short - after I was finished, it was a matter of a few hours to collect information during another stress test and another hour to analyze and fix the leaks.
I'll be more than happy to share my findings.
P.S. some time did I spend on trying to improve on the previous work. My intention was minimizing false positives (I've seen just about too many of those while developing), so it will also check for allocation/release consistency as well as avoid taking into account allocations that are never leaked.
Edit: Find the tool here
There was a MSDN Magazine article from several years ago that talked about GDI leaks. This points to several different places with good information.
In WinDbg, you may also try the !poolused command for some information.
Finding resource leaks in from a crash dump (post-mortem) can be difficult -- if it was always the same place, using the same variable that leaks the memory, and you're lucky, you could see the last place that it will be leaked, etc. It would probably be much easier with a live program running under the debugger.
You can also try using Microsoft Detours, but the license doesn't always work out. It's also a bit more invasive and advanced.
I have created a Windbg script for that. Look at the answer of
Command to get GDI handle count from a crash dump
To track the allocation stack you could set a ba (Break on Access) breakpoint past the last allocated GDICell object to break just at the point when another GDI allocation happens. That could be a bit complex because the address changes but it could be enough to find pretty much any leak.
What are the steps and techniques to debug an apparent hang due to a deadlock in a Win32 production process. I heard that WinDbg can be used for this purpose but could you please provide clear hints on how this can be accomplished?
This post should get you started on the various options..Check the posts tagged with Debugging..
Another useful article on debugging deadlocks..
Debugging a true deadlock is actually kind of easy, if you have access to the source and a memory dump (or live debugging session).
All you do is look at the threads, and find the ones that are waiting on some kind of shared resource (for example hung waiting in WaitForSingleObject). Generally speaking from there it is a matter of figuring out which two or more threads have locked each other up, and then you just have to figure out which one broke the lock heirarchy.
If you can't easily figure out which threads are locked up, use the method shown in this post here to trace the lock chain for each thread. When you get into a loop, the threads in the loop are the ones that are deadlocked.
If you are very lazy, you can install Application Verifier, then add you module and select just "locks" from the basic test.
then you can run your application under any debugger.
if a critical section deadlock happens you with find the reason right away.
What language/IDE are you using?
In .Net you can view the threads of an application: Debug->Windows->Threads or Ctrl+Alt+H
Debugging deadlocks can be tricky. I usually do some kind of logging and see where the log stops. I either log to a file or to the debug console using OutputDebugString().
The best thing is to start by adding logging statements. Generally I would recommend only around the shared resources that are deadlocking but also adding them in general might point to situations or areas of code you weren't expecting. The much publicized stackoverflow.com database issue actually turned out to be log4net! The stackoverflow team never suspected log4net, and only by examining logging (ironically) showed this. I would initially forgo any complicated tools e.g., WinDgb since using them is not very intuitive IMHO.