.Net winform application.
I used several memory profiler, including CLR profiler, DotTrace memory, Net memory profiler.
The tools gave the result that the allocated memory was 38-40M. But I found that working set was 300-400M in task manager(almost the same size as Peak working set or memory or commit size.
So what's the difference between the two results? What do the results mean?
those tools may show you private bytes or managed heap size, this does not include, e.g. memory mapped file, either page file backed or disk file backed, your app may be r/w ing
big mapped file, so working set looks big, or your app just load too many dll/assemblies.
VMMAP (from sysinternals) can give a clear overview of memory type/size in your app.
Related
First I want to ask whether is it possible for an application to update itself at runtime on same address space?
If yes, what's the best way to implement the logic?
Usecase : My application is running on a board which is connected to network. At runtime if it detects a new version of same application, then how to update the application on same memory address, where previous one is stored.
As per my understanding first we should take the backup of update and at the time of boot load, main application should be updated with backup and then launch the application normally. Am I right?
Usually you can replace the file containing the executable while it's running without problems.
After you update the file, you can start the application like always, and close your running instance.
If you however want to do it at runtime (i.e. without forking or starting new process), I don't think it's possible without extremely weird hacks:
if you plan to "rebase" your program memory with new executable's code, you'd need to figure the stack, memory and instruction pointers for each thread. You'd need to become a disassembler.
if you plan to call a stub in your program after loading it into auxilliary memory segment, that's fine, but you need to figure where the target function is, and what happens if it's gone in your next update. Plus it's totally platform-specific.
if you plan to standardize the above approach by using shared libraries that are dynamically loaded and unloaded, I see no problem - it's very similar to the approach where you restart entire process.
I'd go with replacing just the executable, or the third option if I have a very good reason for this. The last option is nice since it lets you update your application's components separately (but at the same time this might cause you maintenance headaches later on.)
What you need is something akin to a bootloader. In this case: you will have two programs on the device, hereafter referred to as the Loader and the App.
On your initial install of the system: write the App to the beginning of memory and the Loader somewhere further down to give space if the App grows in size in the future. (Keep note of the beginning memory address of the Loader)
The App will run normally as if it was the only program, periodically checking for updates to itself. If it finds an update on the network, use a GOTO to go to the first memory location of your Loader, which will then begin running and can write over the original App with the new App found on the network. At the end of your Loader, GOTO back to the (new) App.
See this Stack Overflow question for ideas on how to GOTO to specific memory addresses. Goto a specific Address in C
I downloaded Red gate ANTS Memory Profiler and profiled my app. I noticed that my app had a lot of unmanaged memory allocated (160MB). So I ran the profiler again with unmanaged memory profiling enabled. The break down of the unmanaged memory as follows:
WindowsCodecs: 45.19MB
CLR: 43.21MB
Allocated by Managed code: 30.23MB
Allocated before profiling started: 2.047MB
d3d9: 595.5KB
Other modules: 67.27MB
Other modules also contains the red gate memory profiler which accounted for 64.94MB of the 67.27MB.
From reading the Red Gate documentation, loading the CLR is expected to be around 40MB and my managed code allocating 30MB seems reasonable. But I am confused by the WindowsCodecs taking up 45MB! I am assuming that WindowsCodex is related to video codecs or playback. My app does not use Windows Media Player media control nor does it do any media playback of any sort (audio or video).
Anybody run into this? It appears my app could get a 45MB memory footprint reduction if I can figure out what is pulling in this dependency.
I observered a behavior that i have a file of 1.2GB [ debug file], which i tried opening in VI editor. The machine was drastically slow. Could someone give explanation of system level why it is being very slow?
Maybe because Vi isn´t suited for such large files? It probably tries to load the whole file in RAM, maybe this trigger swap usage, etc. etc.
You can run top command in parallel window and check the utilization of the Virtual Memory and Shared Memory.
I'm learning to use .Net Memory Profiler and testing the memory usage of Microsoft's DataBindingLab sample project.
.Net Memory Profiler shows total live bytes are 2011015, ie. 2MB.
Process Explorer shows Private Bytes are 56MB.
Obviously, there is such a big difference between the value given by the two tools. Where does the remaining 54MB come from?
I've run into a few OutOfMemoryExceptions with my C#/WPF application and I'm running into some confusing data while attempting to profile the memory usage.
When the app is typically running, Windows Task Manager shows the memory usage as somewhere around 34 MB (bounces around slightly as objects are created and garbage collected). When I run memory profiling applications such as CLR Profiler and dotTrace Memory, they show the total memory usage at around 1.2 MB.
Why this huge discrepancy? What does Task Manager see that these profilers do not?
UPDATE: I added some diag code to my application to print out various memory information every so often via the Process class.
While running my app, I set up a rule in DebugDiag to perform a memory dump in the event of an exception. I forced an exception and the memory dump occurred. At this point, the memory usage of my app (as shown by task manager) jumped from 32 MB to 145 MB and remained there.
You can see this jump in the table below (WorkingSet64). I'm still trying to make sense of all the types of memory info provided by the Process class. How would an external application make the working set of my app grow like this?
Link to data table here.
Using some of the diagnostics tools suggested here, plus the ANTS memory profiler (which is so money) I found the source of the leak.
WPF Storyboard animations leak under .NET 3.5
The WPF BitmapEffect class can cause leaks. The alternative "Effect" class fixes the leak. Link, Link
XAML Merged ResourceDictionaries can cause leak. Link, Link
The "Working Set" memory footprint of an application (memory shown by task manager) is not a good indication of your process' footprint. Outside applications can influence this. Link
The memory profiling tools helped me find that the leaks were mostly in unmanaged code, which made it a real pain to track down. Dealing with these leaks, plus a better understanding of Windows memory (private vs working set) cleared things up.
Prcess Explorer and VMMap, both part of the Sysinternals Suite by Mark Russinovich.