Home Dashboard Directory Help
Search

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


Status: 

Closed
 as Fixed Help for as Fixed


5
0
Sign in
to vote
Type: Bug
ID: 546430
Opened: 3/31/2010 12:30:28 PM
Access Restriction: Public
0
Workaround(s)
view
3
User(s) can reproduce this bug

Description

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)
{
    Console.WriteLine(processModule.FileName);
}

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.
Details
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:
    [StructLayout(LayoutKind.Sequential)]
    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;
    };

    [StructLayout(LayoutKind.Explicit)]
    public struct PROCESSOR_INFO_UNION
    {
        [FieldOffset(0)]
        internal uint dwOemId;
        [FieldOffset(0)]
        internal ushort wProcessorArchitecture;
        [FieldOffset(2)]
        internal ushort wReserved;
    }

    [StructLayout(LayoutKind.Sequential)]
    public struct MEMORY_BASIC_INFORMATION
    {
        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
    {
        [DllImport("kernel32.dll")]
        public static extern int VirtualQuery(ref uint lpAddress, ref MEMORY_BASIC_INFORMATION lpBuffer, int dwLength);

        [DllImport("kernel32.dll")]
        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
Hi!
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.


Caveat
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 http://blogs.msdn.com/bclteam

Regards
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?

-Dmitrii
Posted by Microsoft on 5/14/2010 at 4:58 PM
Hi,

This is a breaking change and has been documented here: http://msdn.microsoft.com/en-us/library/ee941656.aspx#core

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

Thanks,
-Abhishek
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.
Sign in to post a workaround.
File Name Submitted By Submitted On File Size  
ModulesBug.zip 3/31/2010 58 KB