locked
When impersonating users, should Process.MainModule fail consistently? RRS feed

  • Question

  • We have a WCF (.Net 3.1 sp1) application that impersonates the requesting client user’s Windows identity.  Because some requests require the service to make its own requests to another WCF service, we are employing delegation and the first host in the chain is running as a Windows service under the Network Service account.  Both WCF services are running on Windows Server 2003.

    That first WCF service sometimes has to call a business system API (not another WCF Service) and occasionally it is throwing an exception that includes the following:

    ....System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ComponentModel.Win32Exception: Access is denied   at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)

        at System.Diagnostics.NtProcessManager.GetModuleInfos(Int32 processId, Boolean firstModuleOnly)

       at System.Diagnostics.NtProcessManager.GetFirstModuleInfo(Int32 processId)

       at System.Diagnostics.Process.get_MainModule()

       at PCI.PFramework.Client.ConfigManager.GetAppPath()

       at PCI.PFramework.Client.ConfigManager.FileExists(String& filePath)

       at PCI.PFramework.Client.ConfigManager.InitDocs()

       at PCI.PFramework.Client.ConfigManager..ctor()

       at PCI.PFramework.Client.SingletonConfigManagerProvider..ctor()

       --- End of inner exception stack trace ---

    This business system API is supplied by a third party vendor and we have no control or access to their code.

    I was able to find references to this kind of problem such as the Community Content section at the bottom of http://msdn.microsoft.com/en-us/library/system.diagnostics.process.mainmodule(VS.90).aspx

    What I found indicates this kind of problem occurs when accessing the Process object during impersonation.  What I have not found was any mention of this problem occurring consistently or sporadically as we are observing in our application.

    We have users who are working fine and then without any noticeable cause, begin to see this error.  A few minutes later using the same account and software, they’re back to working fine .

    If the root of our problem is that one user’s context is attempting to access the Process information of the other as the articles indicate, why would it ever work?

    Frankly, one worry I have is that this IS the cause and that the times it actually works are due to a security bug in .Net or Windows.  If that’s the case it’s probable that someday a patch from Microsoft will cause it to fail always and the customer will be dead in the water.

    So, the key questions are:

    1.       Is there another root cause possibility that is NOT the impersonation and Process object thing?

    2.       If it is the impersonation and Process object thing, why wouldn’t it always fail?

    3.       Is there some configuration or set of steps available to me to work around this - considering that I can't modify the API?

    Thanks in advance for your responses!

     

    • Moved by eryang Tuesday, July 20, 2010 12:37 AM (From:.NET Base Class Library)
    Friday, July 16, 2010 7:16 PM

All replies