It's hard to do if you don't have access to the initial state and there's very little closure on allocations in an already running process. Consider the difficulty. At the moment of attachment, some number of memory allocations are sure to have already been committed. Without a record, there's no list to check off when memory is returned to leave a residue of unreturned requests. A tool could start memory tracking at the point of attachment, but the same problem exists at the other end of the test run: which of the recorded allocations is still out because the service is still using it and which are leaked memory? Such problems lower the confidence level of memory leak results and make it hard to justify coding efforts for such partial results. Similar arguments can be made for race detection and knowing who was the last writer of every written memory location.
Sorry, I don't buy that. You should be able to test the memory from any snapshot of a time frame, to any other snapshot at a later time. If I require to test a dll, which is ran by a complicated app, or I need to test for leaks before the app ends at a specific duration, I should be able to do that.
Well, attaching Intel Inspector to a process at some arbitrary point in its executionand testing a DLL before the app ends are two very different tasks. Whereas in the former, when Intel Inspector begins its analysis it has no clue regarding what came before, what memory allocations were made, where their boundaries lie, or even how many allocations have been made--forget leak testing and bounds testing on any allocations that occurred before the attach. Picking out a particular DLL (or a set) for testing assumes that the tool was there from the beginning (at least of the DLL run) and gives the tool a chance to capture such allocation data over the duration of DLL activities. And coincidentally, Intel just released Intel Inspector XE 2011 for Windows* Update 5 to provide just such a feature:
Enhanced module inclusion/exclusion capability when configuring projects for analysis - for example, you can inspect specific modules and disable inspection of all other modules, or disable inspection of specific modules and inspect all other modules