locked
ICorPublish.GetProcess throws System.ArgumentException: Value does not fall within the expected range.

    Question

  • Hey,

    I am trying to get a process by it's id and when I call ICorPublish.GetProcess(id, out ICorPublishProcess) I get an exception: System.ArgumentException: Value does not fall within the expected range. The process is a .NET 2.0 console application. If I convert it to .NET 4.0, (the debugger core is a .NET 4.0 library), the method succeeds.

    How can I fix this?


    Eusebiu
    Tuesday, November 30, 2010 8:28 PM

Answers

  • It may not be what you are hoping to hear, but ICorPublish is constrained by both version and bitness. If you create the 4.0 version of the ICorPublish interface in a 32 bit app, then it will only be able to enumerate processes that have 32 bit version 4.0 CLR in them. If you want to detect 2.0 CLR apps you would need to use the 2.0 version of ICorPublish.

    Depending on your goals you might be able to accomplish your task in other ways as well:

    1) If you just want a moderately accurate guess of whether clr is loaded you can use toolhelp's module enumeration and search for mscorwks.dll or clr.dll.

    2) In CLR version 4.0 onwards there are a wide variety of documented ETW events you can trigger. Runtime information and AppDomain information are included.

    3) In CLR version 4.0 onwards ICLRDebugging::OpenVirtualProcess can tell you if CLR is loaded, and optionally gives you an ICorDebugProcess from which a subset of the debugging APIs are available.

    In general ICorPublish isn't receiving a lot of continued investment. While we haven't removed it we also haven't done all the extra work it would take to make it work in across different major versions or across different bitness. Instead we are investing more of our efforts at improving some of other diagnostics so that they can better handle the niche that ICorPublish currently fills.

    HTH,

      -Noah

    Thursday, April 26, 2012 5:21 AM
    Moderator

All replies

  • I changed the signature of the GetProcess method to return int and set the PreserveSig attribute and the result is -2147024809 (0x80070057).

    I searched this error on web, and it looks like there's a parameter who causes this error.

    The process id is a valid one(MDbg recognize the console app) and the out ICorPublishProcess is also correct (since it works for .NET 4.0 apps).

    [PreserveSig] public virtual extern int __GetProcess([In] uint pid, [MarshalAs(UnmanagedType.Interface)] out ICorPublishProcess ppProcess);


    Eusebiu
    Tuesday, November 30, 2010 10:41 PM
  •  

    Hi,

     

    Thank you for your question. We're doing research on this case. It might take some time before we get back to you.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, December 03, 2010 3:35 AM

  • Hi, With a search I found some links that may be help full for you, I have not found exact same error at this time.
     

    ICorPublish::GetProcess Method

    http://msdn.microsoft.com/en-us/library/ms232609(v=VS.80).aspx
    GetProcess fails if the process doesn't exist, or isn't a managed process that can be debugged by the current user.

    ICorPublish Interface
    http://msdn.microsoft.com/en-us/library/ms231592(v=VS.80).aspx

    CorpubPublish Coclass
    http://msdn.microsoft.com/en-us/library/aa964720(v=VS.80).aspx

    Debugging my debugger - ICorDebug and the ramifications of thread suspension

    http://clrsleuth.blogspot.com/2010/10/debugging-my-debugger-icordebug-and.html


    http://social.msdn.microsoft.com/Forums/sl-SI/netfxtoolsdev/thread/207ce40e-86f9-4f0b-8687-ff2183c598c4
     

    ICorDebug Interface
    http://msdn.microsoft.com/en-us/library/ms230588.aspx


    ICorDebugMetaDataLocator Interface

    http://msdn.microsoft.com/en-us/library/dd646503.aspx


    ICorDebugMetaDataLocator::GetMetaData Method

    http://msdn.microsoft.com/en-us/library/dd646513.aspx

    Debugging Interfaces
    http://msdn.microsoft.com/en-us/library/ms404484.aspx


    bill boyce
    Wednesday, December 29, 2010 5:04 PM
    Moderator
  • Hi Eusebiu,

    Could you please paste the code showing how you create an instance of the ICorPublish and then how you call the GetProcess method?

    I am not sure if this will be of any help but you may compare your signatures with the ones from mdbg:

       [ComImport, Guid("9613A0E7-5A68-11D3-8F84-00A0C9B4D50C"), CoClass(typeof(CorpubPublishClass))]
       public interface CorpubPublish : ICorPublish
       {
       }
    
       [ComImport, TypeLibType(2), Guid("047a9a40-657e-11d3-8d5b-00104b35e7ef"), ClassInterface(ClassInterfaceType.None)]
       public class CorpubPublishClass : ICorPublish, CorpubPublish
       {
         [MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
         public virtual extern void EnumProcesses(
            [In, ComAliasName("CorpubProcessLib.COR_PUB_ENUMPROCESS")] COR_PUB_ENUMPROCESS Type, 
            [Out, MarshalAs(UnmanagedType.Interface)] out ICorPublishProcessEnum ppIEnum);
    
         [MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
         public virtual extern void GetProcess([In] uint pid, [Out, MarshalAs(UnmanagedType.Interface)] out ICorPublishProcess ppProcess);
       }
    
       [ComImport, Guid("9613A0E7-5A68-11D3-8F84-00A0C9B4D50C"), InterfaceType(1)]
       public interface ICorPublish
       {
          
          void EnumProcesses([In, ComAliasName("CorpubProcessLib.COR_PUB_ENUMPROCESS")] COR_PUB_ENUMPROCESS Type, [Out, MarshalAs(UnmanagedType.Interface)] out ICorPublishProcessEnum ppIEnum);
          
          void GetProcess([In] uint pid, [Out, MarshalAs(UnmanagedType.Interface)] out ICorPublishProcess ppProcess);
       }
    

    Best regards,

    consept

    Sunday, January 16, 2011 9:46 AM
  • Hey..

    The definitions are the same...

    corPublish = new CorpubPublishClass();ICorPublishProcess process = corPublish.GetProcess((uint)processId);
    
    ...
    public static ICorPublishProcess GetProcess(this ICorPublish instance, uint pid)
    {
    	ICorPublishProcess ppProcess;
    	instance.__GetProcess(pid, out ppProcess);
    	return ppProcess;
    }
    

    Thanks,

    Eusebiu


    Eusebiu
    Sunday, January 16, 2011 1:48 PM
  • I have the same issue.

    I use CLR Managed Debugger (mdbg) Sample 4.0 from here: http://www.microsoft.com/download/en/confirmation.aspx?id=2282.

    It throws the same exception as above when trying to invoke GetProcess with PID of CLR 2.0 application.

    Thursday, April 05, 2012 1:57 PM
  • It may not be what you are hoping to hear, but ICorPublish is constrained by both version and bitness. If you create the 4.0 version of the ICorPublish interface in a 32 bit app, then it will only be able to enumerate processes that have 32 bit version 4.0 CLR in them. If you want to detect 2.0 CLR apps you would need to use the 2.0 version of ICorPublish.

    Depending on your goals you might be able to accomplish your task in other ways as well:

    1) If you just want a moderately accurate guess of whether clr is loaded you can use toolhelp's module enumeration and search for mscorwks.dll or clr.dll.

    2) In CLR version 4.0 onwards there are a wide variety of documented ETW events you can trigger. Runtime information and AppDomain information are included.

    3) In CLR version 4.0 onwards ICLRDebugging::OpenVirtualProcess can tell you if CLR is loaded, and optionally gives you an ICorDebugProcess from which a subset of the debugging APIs are available.

    In general ICorPublish isn't receiving a lot of continued investment. While we haven't removed it we also haven't done all the extra work it would take to make it work in across different major versions or across different bitness. Instead we are investing more of our efforts at improving some of other diagnostics so that they can better handle the niche that ICorPublish currently fills.

    HTH,

      -Noah

    Thursday, April 26, 2012 5:21 AM
    Moderator