For System.Data.DataRowView instance displayed as "#28,085,692, hex equivalent is 1AC8DBC
If I take that into "!Dumpobject":
0:000> !do 1ac8dbc
<Note: this object has an invalid CLASS field>
How can I display the actual dump object instance address of an instance# shown in MemProfiler?
However, when importing memory dumps, things are a bit different. As you have noticed, the memory address would be useful to get additional info about an instance using the !DumpObject command in WinDbg. And since the profiler has no way of knowing how instances are moved in memory between two memory dumps, no instance tracking takes place, and a new instance number is assigned to all instances for each snapshot. So theoretically, the memory address could be used. But, to improve memory usage, the instance number is just a 32-bit number, which would prevent using the address in a 64-bit process.
To sum it up. No, there's currently no way of associating an instance number with the instance address. In the next version of the profiler (v4.1) we might add this information for snapshots collected using a memory dump. Unfortunately, this will add an additional 4 or 8 bytes to each instance in the snapshot.
SciTech Software AB
But it would be extremely valuable to be able to relate the information out of MemProfiler to further analysis via WinDbg.
The dump set I am currently analyzing has what looks like an event handler related leak and a data-binding link. I need to follow several pointer chains to provide enough information for the developer to identify the scenario causing the leaks. But with 14 million instances, a simple "!dumpheap -type" of one of the suspect class types literally took two days just to complete! There is no way I could ever run "gcroot" on any significant number of instances.
So getting all of the information through WinDbg (where I DO get the instance addresses) is not really an option. By importing the dump into MemProfiler and using your "roots" displays, I can narrow down the instances of interest. With this "instance address" feature, I could then follow the chains back in WinDbg without having to use WinDbg to initially identify the instances with the problem root.
In this scenario, it would also be extremely helpful if there was a way for you to add a feature to copy the entire, fully expanded "Field Values" treeview. (This is the popup from the popup dialog off of the "Type Details" tabthat has both "Field Values" and "Allocation Call Stack"). That dialog cannot be re-sized, so it is difficult to see enough of the "Field Values" tree at any one time to get a feel for the available data; particulary since I' not familiar enough with the application I'm analyzing to know what I'm looking for in terms of field names and tree node depth.
I would love to be able to right-click that "Field Values" tab and copy that whole, fully expanded treeview of Field Values data to the clipboard. I could then paste it into an EMail or Word document for the developer and I to look at the whole tree in total.
Thank you again for replying.
May I ask what kind of information you want to extract using WinDbg, that is not available in the profiler?
SciTech Software AB
We have also planned to add better scripting support to the profiler. Currently scripting is possible by accessing the SciTech.NetMemProfiler.Core assembly, but no public documentation is yet available. This assembly is used by the profiler application itself and it has become pretty complex and is also being refactored occasionally, so it is not very suitable for public access. Maybe we will add a smaller API interface as a facade to SciTech.NetMemProfiler.Core.
Better reporting is another feature that has been planned for a long time, but has been postponed for several versions. Do you have any specific ideas on how you'd like the reporting to work?
SciTech Software AB
The main "Overview" grid with a header that includes the settings that tailored it (i.e.: "Show Types" settings, etc.)
The "Root Paths" display along a header that includes the settings that tailored it (i.e.: "truncate root paths" settings, etc.)
On the "Instance Details" display, the selected, or optionally all (one-at-a-time)the Root Path text description
On the "Instance Details" display, the selected, or optionally all (one-at-a-time) complete, non-truncated instance graph
Wherever it shows, the information on "Info/Fields" tabs. An option would allow you to either fully expand the "Fields" treeview or else just to print it showing the nodess expanded/collapsed just as I had currently made them via clicking or not clicking on the node plus/minus signs.
Note that you can copy information to the clipboard from the different views in the profiler. However, the way of doing it is unfortunately not the same everywhere:
The data in the Oveview grid (and all other grids) can be copied using the Edit->Copy all (Ctrl+Shift+C) command, or using the Copy all command in the context menu. To print the data you will probably need to paste it into Excel or similar. The current settings for the grid are currently not included.
Root paths and allocation stacks can be copied using the Edit->Copy (Ctrl+C) command, or using the Copy command in the context menu. Information in the info view is currently no included.
The full instance graph can be copied as a bitmap using the Edit->Copy (Ctrl+C) command (there's currently no Copy in the context menu).
The fields tree under Instance details can be copied using Edit->Copy (Ctrl+C) command, or using the Copy command in the context menu. The fields tree in popup windows can only be copied using the context menu. Only already expanded items will be copied (a fully expanded tree can be very big).
Finally you can copy the information presented in the info views by selecting the text (e.g. using Ctrl+A or the mouse) and pressing Ctrl+C (Edit->Copy cannot currently be used and there's currently no context menu).
So by copying data to the clipboard and pasting it into another program (e.g. Excel), you have the possibility to extract information for presentation. However, this can obviously made much easier by adding built-in reporting, the possibility to export to file and to print. And some of the information that might be useful, e.g. filter settings, is currently not included.
SciTech Software AB
I just wanted to check the status of my request to include the address of an instance as an additional property when importing a memory dump. I've been fighting a low-memory condition for a large ASP.NET application for days. I've found a few paths of interest in MemProfiler's object graphs, but there are so many instances of the classes involved that I cannot find them in the dump. In this particular case, there are generic collections of interest. MemProfiler just shows them as List<T>. I'd need to find the actual instance to find out what class type is involved in the collection. (The mouse-over fly-out "Fields" display in MemProfiler just shows "No instance data collected). I'm having the same problem with some HashTables of interest - some of which seem to be rooting suspicious numbers of instances but there are so many in the dump I can't find the matching instances. Again, MemProfiler's Fields context fly-out shows "no instance data collected".
In our previous discussion on this feature, you were concerned about the amount of memory required to carry the instance address around; not to mention the GUI changes to access it and display it. I have a suggestion for a much lower impact way to achieve the same result. How about adding an option to simply write out a cross-reference file while you are importing a dump? As you assign each new instance your unique sequential number, just write out that index number and the underlying instance address to a disk file. The output format could be a simple flat file, a compressed binary file with matching simple search utility, or some searchable format like an .MDB. This solution would require no additional memory during any of the run-time for MemProfiler except a small amount during the "import" itself.
Yet the resulting file could still be used to find the corresponding dump address that matches a MemProfiler non-meaningful but unique sequential number for later use with WinDbg, PowerShell, PowerDbg, or Visual Studio. You could simply add the option as a checkbox and an output path text control to the "Import Memory Dump dialog. Or if you wanted the cheapest possible implementation, you could even add no GUI at all and make producing such a cross-reference file a commandline-only option.
You have such a great tool! But this would really help when bouncing back and forth with WinDbg. Please, please, please move this up higher on your "To Do" list.
In version 4.6 you will get the option to include instance addresses when importing memory dumps. The instance address is presented as an additional column in the instances list. And in the instance details info panel. The release of .NET Memory Profiler 4.6 has been somewhat delayed, but hopefully a beta will be available by the end of the month (February).
SciTech Software AB
Users browsing this forum: No registered users and 15 guests