WMI Error: System.Runtime.InteropServices.COMException (0x80040208)

07 Nov
November 7, 2012

Lovely post title, and a very annoying error.

I ran into this error while trying to communicate with Windows Management instrumentation in order to get the PathName installation parameter of the MSReportServer_ConfigurationSetting class (which hooks up to a Report Server instance). The issue is a very vague COM exception that doesn’t really give much information, what made the issue worse is that it is not a connection issue to the WMI Namespace, which works absolutely fine, the issue happens when my code tries to load any data from the namespace that I already successfully established a connection to.

In this post I will be giving a very brief introduction into WMI for Reporting Services, the reason this issue was happening, and how I managed to resolve this issue for my particular case.

Without going into too much details, WMI (or Windows Management Instrumentation) is a service that allows you to programmatically query and manage different aspect of the Windows OS system, so for example you could query what process are currently running, what are the available disks on the machine, etc.

WMI can report on Reporting Services (SSRS) and allows users to query ConfigurationSettings as well as some basic information regarding the instance of SSRS. There are two supported classes:

 

Now my code was essentially calling the ConfigurationSettings class in order to find out the installation PathName for a particular instance of SSRS, the code was working fine on our servers until we migrated to a new environment that caused the following error message:

System.Runtime.InteropServices.COMException (0x80040208)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)

To cut a long (and painfully annoying to debug) story short, in my case this was a security issue, I managed to test this by writing a small console application that implements the connection to the SSRS WMI which I then ran once in a Commandline that has not been elevated to Admin, and another that has been elevated to run as Administrator, the elevated access one worked fine.

So, since its a security issue, in order to resolve the issue I followed these 2 steps:

  • The first thing to do is make sure that whatever user account is running the WMI implementation has the rights to access WMI services and COM/DCOM objects: I found an article that goes through enabling WMI access for non-admin domain users. Although the article is related to Splunk (logging solution) setup, it is still applicable to any user that is trying to access WMI services. Although in my case the account was setup with all the relevant security features needed to run WMI.
  • Disable UAC (User Control Access): This is actually what worked for me, for some reason even though the account has all the relevant access rights, it still could not execute the WMI script without throwing the error above, disabling UAC will essentially mean that everything will run under the highest privilege, which is exactly what I needed.

So this basically solved the issue, and the WMI service can be queries no problem now, but the solution is not very elegant, since disabling UAC might be considered a system vulnerability, the better way is to ensure that whatever application you have accessing WMI is doing so with the elevated privileges, in my case that was not possible.

One last thing to note here, in order to quickly connect to a WMI instance (locally or on a remote computer), run queries or even edit/update values, you can use the built-in windows tool WBEMtest, which can be reached by clicking on the Start menu, then click on Run and type WBEMtest, very handy if you just want to make sure everything is on the up and up.

WMI Error: System.Runtime.InteropServices.COMException (0x80040208) rated 4 out of 5 by 1 readers

WMI Error: System.Runtime.InteropServices.COMException (0x80040208) , 4.0 out of 5 based on 1 ratings
* * * * ½ 2 votes
Tags: , , ,
3 replies
  1. camelya says:

    Hi, Ibrahim!
    I am struggling with exactly same error right now – WMI is not working when SSRS Service account is LOCAL SERVICE OR NETWORK SERVICE. Your article really helped me to understand the nature of this error. But, unfortunately, given solutions are not working in my case.
    Maybe, you have discovered other details since then??
    Thank you
    P.S.
    My post to SSRS forum

    Reply
    • admin says:

      Hi Camelya,

      It is frustrating isn’t it? :)

      For my particular scenario the solution above was sufficient, so I did not investigate the problem further. But maybe (maybe being the operative keyword here) this article can help, since you are dealing with local accounts rather than domain accounts:

      Essentially what you are trying to do is give a local account access to WMI, in order to do that you would roughly need to:

      1) add the user (LOCAL SERVICE/NETWORK SERVICE to the “Distributed COM Users” and “Performance Monitor Users” user group (use the snap-in window: lusrmgr.msc)

      2) Edit the “Launch and Activation Permissions” on your COM objects (through COM Security tab in the “My Computer” branch using the snap-in window: dcomcnfg). Make sure the above user groups have access for local and/or remote launch and activation.

      3) Edit WMI security for those 2 user groups, this can be done using the snap-in window: wmimgmt.msc

      Although my recommendation (and this is a bit of a side issue) is to not use the default local service accounts to run those services, instead I would customize either a local or domain account instead… but u probably already know that :)

      Reply
  2. camelya says:

    Hi, Ibrahim!
    Thank you,once again!
    I’ve carefully read article you suggested!
    The truth is, I already set this all permissions for Network service and Local Service, but individually. Now I’ve added accounts to DCOM Users Group and Performance Monitor Users Group and repeated this sequence for groups. Unfortunately, nothing changed for the better. The only thing I am not sure are security permisiion desciptors for ReportServer service – I just have copied ones from article. Now I have to look into this DECRIPTOR’s subject more closely. But, I can tell you that my hope is almost gone (:

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply to admin Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>