System.Diagnostics.Process.Modules doesn't include managed dlls. - by Dmitrii Zakharov

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 546430 Comments
Status Closed Workarounds
Type Bug Repros 3
Opened 3/31/2010 12:30:28 PM
Access Restriction Public


This is a bug in System.Diagnostics.Process.Modules. 
In .NET 3.5 it used to be possible to list all the modules, including managed dlls, loaded into current process. In .NET 4.0 only unmanaged dlls are listed.

Here’s code snippet that demos the problem:

foreach (ProcessModule processModule in Process.GetCurrentProcess().Modules)

This has been confirmed internally by a CLR developer (Karel Zikmund).

Impact: our company will have to rewrite a substantial part of our .NET oriented product if this is not fixed.
Sign in to post a comment.
Posted by phoenicyan on 9/17/2012 at 1:33 PM
VirtualQuery did not work - mbi.Type always returned MEM_PRIVATE (0x20000). Here is code attempted:
    public struct SYSTEM_INFO
        internal PROCESSOR_INFO_UNION p;
        public uint dwPageSize;
        public IntPtr lpMinimumApplicationAddress;
        public IntPtr lpMaximumApplicationAddress;
        public UIntPtr dwActiveProcessorMask;
        public uint dwNumberOfProcessors;
        public uint dwProcessorType;
        public uint dwAllocationGranularity;
        public ushort wProcessorLevel;
        public ushort wProcessorRevision;

    public struct PROCESSOR_INFO_UNION
        internal uint dwOemId;
        internal ushort wProcessorArchitecture;
        internal ushort wReserved;

        public UIntPtr BaseAddress;
        public UIntPtr AllocationBase;
        public uint AllocationProtect;
        public IntPtr RegionSize;
        public uint State;
        public uint Protect;
        public uint Type;

    internal static class Win32
        public static extern int VirtualQuery(ref uint lpAddress, ref MEMORY_BASIC_INFORMATION lpBuffer, int dwLength);

        public static extern void GetSystemInfo([MarshalAs(UnmanagedType.Struct)] ref SYSTEM_INFO lpSystemInfo);

    public static class XYZ
        internal static SYSTEM_INFO system_info;
        internal static MEMORY_BASIC_INFORMATION mbi;

        internal static Assembly[] GetModules()
            Win32.GetSystemInfo(ref system_info);

            const uint MEM_MAPPED = 0x40000;
            for (; system_info.dwPageSize < 0x80000000
                && Win32.VirtualQuery(ref system_info.dwPageSize, ref mbi, (int)System.Runtime.InteropServices.Marshal.SizeOf(mbi)) != 0;
                system_info.dwPageSize += (uint)mbi.RegionSize)
                if ((mbi.Type & MEM_MAPPED) != 0)
// never comes here
Posted by Rhobison on 6/2/2011 at 12:41 PM
How to do this workaround in Windows Mobile? The function GetMappedFileName() is not available.
I need to check if some application is using my managed dll.
Posted by Microsoft on 6/15/2010 at 11:01 AM
Hello Dmitrii,

Here is the workaround.

If you are trying to enumerate all mapped files in a process, you can do a VirtualQuery call which gives a short description of every blob of accessible memory. The Type bit on the PMEMORY_BASIC_INFORMATION tells you if it a mapped file (with have a value of MEM_MAPPED), and if it is a mapped file, you can call GetMappedFileName() which tells you what file it is, effectively giving you what you had with Process.GetCurrentProcess().Modules.

This will not work for all assemblies (and never did even when you used Process.GetCurrentProcess().Modules) because we dont map every IL assembly. e.g. IL images with NGEN images)

I will check about the feasiblity of putting a sample code on the bcl blog at

Vipul Patel
Base Class Libraries
Common Language Runtime Team
Posted by Dmitrii Zakharov on 5/14/2010 at 5:37 PM
Is there a workaround for this?

Posted by Microsoft on 5/14/2010 at 4:58 PM

This is a breaking change and has been documented here:

Please look under "Reflection" in the "Core" section.

Posted by Microsoft on 3/31/2010 at 7:41 PM

Thanks for your feedback. We were able to reproduce the issue you are seeing. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.