Sysinternals Homepage
Forum Home Forum Home > Windows Discussions > Development
  New Posts New Posts RSS Feed - Why some .Net assemblies are duplicated in memory
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Why some .Net assemblies are duplicated in memory

 Post Reply Post Reply Page  12>
Author
Message
cedrou View Drop Down
Newbie
Newbie


Joined: 16 June 2008
Location: France
Status: Offline
Points: 16
Post Options Post Options   Thanks (0) Thanks(0)   Quote cedrou Quote  Post ReplyReply Direct Link To This Post Topic: Why some .Net assemblies are duplicated in memory
    Posted: 02 July 2008 at 10:10am
Hi everybody

I'm developing a virtual memory explorer that tries to identify each block in process' userland.
It uses the loader info structure to get the list of loaded modules and afterward scans the whole virtual memory (as CDB does with .imgscan) to find MZ signatures of "unknown modules" that aren't in this list.

For the majority of processes, the number of 'Unknown modules' is small (2 or 3) and they are all found in ProcessExplorer's DLL panel as 'Data mapped'.
These modules are generally resources DLLs or dynamically generated assemblies (like XML Serializers).
But, I found that some of these unknown modules were the duplication of other modules that are already loaded in memory.

After some tests, it appeared that these duplicated modules are :

    * always .Net assemblies,
    * independent of the source language (C#, C++/CLI, ...),
    * independent to the fact that they're strongly signed or not, in the GAC or not,
    * not found in ProcessExplorer's DLL panel,
    * binary identical, except of four bytes in the image header (entry point address),
    * loaded implicitly (reference of the main assembly) or explicitly (with Assembly.Load)


An .imgscan command lists these duplicate DLL's and it can identify them !
I really don't know if it probes from the header or the resources of the module or if it found a list.

I then used ProcessMonitor with the filter "Include Operation is Load Image" to get the call stack when they are loaded.
The assemblies that are duplicated produce 3 entries in this order (addresses are exemples):

   1. Image Base: 0x11f0000 and the stack reveals the method mscorwks.dll!CLRMapViewOfFileEx
   2. Image Base: 0x1200000 and the stack reveals the method mscorwks.dll!CLRMapViewOfFileEx
   3. Image Base: 0x11f0000 and the stack reveals the method mscorwks.dll!CLRLoadLibrary


The module at 0x11f0000 is the one that is listed in process module.
The module at 0x1200000 is an "unknown module".

I have several questions related to this:

   1. Why are these Dll's loaded twice in memory ?
   2. Is it possible and how can I get rid of that ?
   3. How .imgscan identify these modules ?
   4. How can I get the list of mapped files in a process virtual memory ?


I have uploaded an archive with a sample case and the stacks output from ProcessMonitor.

thanks for your answers, commentaries or ideas.

cedrou

Back to Top
hawiianheimer View Drop Down
Newbie
Newbie


Joined: 20 April 2009
Status: Offline
Points: 2
Post Options Post Options   Thanks (0) Thanks(0)   Quote hawiianheimer Quote  Post ReplyReply Direct Link To This Post Posted: 20 April 2009 at 4:42pm
Cedric,
 
Unfortunately, I don't have any information to add to what you've already discovered, but I've observed some of the same things.
 
I've used your VMExplorer tool, and it appears that you've categorized the duplicate assembly images under "Mappings".  I was wondering whether this implies that you've discovered something about these images, and whether there's a way to eliminate them.
 
In any event, thanks for creating VMExplorer.  It looks like it will be quite useful, and some of the enhancements you've listed look like they may be very helpful for me.
 
Mark
 
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Status: Offline
Points: 17531
Post Options Post Options   Thanks (0) Thanks(0)   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 20 April 2009 at 4:47pm
FWIW...

An inquiry that seems related to this discussion can be found here:
VMMap duplicate .NET Assemblies
Daily affirmation:
net helpmsg 4006
Back to Top
wj32 View Drop Down
Senior Member
Senior Member
Avatar

Joined: 16 January 2009
Location: Australia
Status: Offline
Points: 1021
Post Options Post Options   Thanks (0) Thanks(0)   Quote wj32 Quote  Post ReplyReply Direct Link To This Post Posted: 20 April 2009 at 10:13pm
Perhaps it is used by the .NET JIT compiler? How big is the mapping (is it the entire DLL)?
PH, a free and open source process viewer.
Back to Top
cedrou View Drop Down
Newbie
Newbie


Joined: 16 June 2008
Location: France
Status: Offline
Points: 16
Post Options Post Options   Thanks (0) Thanks(0)   Quote cedrou Quote  Post ReplyReply Direct Link To This Post Posted: 21 April 2009 at 10:32am
Mark: 
I didn't found any explanation for these duplicate files, but with the help of the function GetMappedFileName (PSAPI) I was able to identify and name them. 
Which enhancement of VMExplorer would be useful for you ? 

wj32:
Yes, it is the entire DLL and it is binary identical to the loaded DLL, except of the address of the entry point.
I don't think it's for the JIT compiler: the CLI instructions can be read from the loaded DLL and the compiled code is written elsewhere in memory.
I've thought about a sort of shadow copy mechanism: we could update the DLL without restarting the process. This feature exists for ASP.net applications, and i've tried to add in the manifest the instructions to disable this, but nothing has changed.
I thought it was a way to access some resources (forms, bitmaps, ...) but assemblies without such resources behave the same way.

I've start reading SSCLI source code to try to understand this behavior, but this code is really complex and I gave up quickly. The Mono code seems easier to read, but I don't know if this happens with Mono too...
VMExplorer: Explore your processes memory.
Back to Top
hawiianheimer View Drop Down
Newbie
Newbie


Joined: 20 April 2009
Status: Offline
Points: 2
Post Options Post Options   Thanks (0) Thanks(0)   Quote hawiianheimer Quote  Post ReplyReply Direct Link To This Post Posted: 21 April 2009 at 6:08pm
Cedrou,
Thanks for your response.  I think I'll try asking this question on the MSDN CLR forum, and see what I can discover.
 
The VMExplorer enhancements of greatest interest to me were the ability to open crash dump files and the statistics module for heap fragmentation.
 
Mark
Back to Top
tong View Drop Down
Newbie
Newbie


Joined: 29 June 2009
Status: Offline
Points: 1
Post Options Post Options   Thanks (0) Thanks(0)   Quote tong Quote  Post ReplyReply Direct Link To This Post Posted: 29 June 2009 at 3:37pm
Is there any update on this?

Thanks!
Back to Top
rifujarcxjtnkh View Drop Down
Newbie
Newbie
Avatar

Joined: 09 July 2009
Status: Offline
Points: 1
Post Options Post Options   Thanks (0) Thanks(0)   Quote rifujarcxjtnkh Quote  Post ReplyReply Direct Link To This Post Posted: 09 July 2009 at 8:17pm

Apparently Microsoft knows about the issue and "are working on identifying a fix".

Have a look over here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=467560 
Would be nice to know what the similar issue is (and of cause having the fix too Smile).
Back to Top
ToFr View Drop Down
Newbie
Newbie
Avatar

Joined: 14 January 2009
Location: Netherlands
Status: Offline
Points: 6
Post Options Post Options   Thanks (0) Thanks(0)   Quote ToFr Quote  Post ReplyReply Direct Link To This Post Posted: 28 July 2010 at 8:08pm
Hi,
 
This problem seems to have been solved in version 4 of the CLR.
 
Regards,
ToFr
Regards,
ToFr
Back to Top
Poorguy View Drop Down
Senior Member
Senior Member
Avatar

Joined: 17 July 2006
Location: Argentina
Status: Offline
Points: 443
Post Options Post Options   Thanks (0) Thanks(0)   Quote Poorguy Quote  Post ReplyReply Direct Link To This Post Posted: 30 July 2010 at 12:17am
Sounds to be as "garbage collector"Wacko...

Edited by Poorguy - 30 July 2010 at 12:17am
Luis Fernando De La Fuente
Back to Top
 Post Reply Post Reply Page  12>
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 11.06
Copyright ©2001-2016 Web Wiz Ltd.