I have an application (C++) that uses WMI to query a service. For one service on the machine, I'm getting "empty" values (as displayed in CIM Studio) for DesktopInteract, InstallDate, PathName, StartName, and TagId. The big problem for me is the StartName property. Using the MMC "Services" snap-in, the "Log On" account is visible (and correct); RegEdit likewise shows the value I expect in ObjectName; only WMI seems to be affected. Other services that have the same StartName are unaffected, as well. Under what circumstances will WMI be unable to report the service start name (and other properties)? Is this a "normal" condition that I'll need to take into account, or is it a symptom of a WMI issue? Thanks,
I have performed a quick search in internal databases regarding this issue. However, I did not find any reported records yet.
To isolate if this issue is that service specific, have you tried to run your code on a second machine with this service installed? If it can be reproduced easily, I would recommend you to provide a little sample project for me to give it a local reproduce(assuming my machine also have this service installed). The local reproduce will help to make the troubleshooting and debugging more convenient.
Anyway, I will perform some further reserach to find out if there is any more informative troubleshooting method.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
WMI uses SC manager APIs to get these information. Services.msc shows the account details and WMI is not able to show, there could be some permission issue.
For instance, e:\Wmi\admin\wmi\wbem\Winmgmt\winmgmt2>sc sdshow winmgmt
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCS W LOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;C CDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
Here only IU is given permission. But, if the same user is trying in batch (or) remote scenario where the token received by WMI is not having interactive RID, WMI will not be able to get the details. Just guessing this may be a problem.
Anyway, more information or a local reproduce will help to identify the root cause more accurate. Thanks.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
I think I've found the problem. Apparently the CIMV2 WMI provider is using a fixed-size buffer when it calls QueryServiceConfig(). If the buffer isn't big enough to hold the results, it fails silently and is unable to display many of the properties of the Win32_Service instance. The service in question has a very long ImagePath; 545 characters (1090 bytes). The clue was SC.EXE, which suffers from the same problem but at least reports the error. Here's an example: C:\>sc \\MYSERVER qc "MyService" [SC] QueryServiceConfig FAILED 122: The data area passed to a system call is too small. [SC] GetServiceConfig needs 1252 bytes
When I changed the service's "ImagePath" in the registry to something shorter, it worked: C:\>sc \\MYSERVER qc "MyService" [SC] QueryServiceConfig SUCCESS SERVICE_NAME: MyService TYPE : 10 WIN32_OWN_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : This is a test. LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : MyService DEPENDENCIES : SERVICE_START_NAME : MYDOMAIN\MyUser
Any ideas on how to work around this? Thanks again,
> I have done some further research on this issue.
> WMI uses SC manager APIs to get these information. Services.msc shows the > account details and WMI is not able to show, there could be some permission > issue.
> For instance, > e:\Wmi\admin\wmi\wbem\Winmgmt\winmgmt2>sc sdshow winmgmt
> D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCS W > LOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;C > CDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
> Here only IU is given permission. But, if the same user is trying in batch > (or) remote scenario where the token received by WMI is not having > interactive RID, WMI will not be able to get the details. Just guessing > this may be a problem.
> Anyway, more information or a local reproduce will help to identify the > root cause more accurate. Thanks.
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues > where an initial response from the community or a Microsoft Support > Engineer within 1 business day is acceptable. Please note that each follow > up response may take approximately 2 business days as the support > professional working with you may need further investigation to reach the > most efficient resolution. The offering is not appropriate for situations > that require urgent, real-time or phone-based interactions or complex > project analysis and dump analysis issues. Issues of this nature are best > handled working with a dedicated Microsoft Support Engineer by contacting > Microsoft Customer Support Services (CSS) at > http://msdn.microsoft.com/subscriptions/support/default.aspx. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights.
I have forwarded this issue to the WMI dev team. They have filed a bug regarding this issue. I will feedback any bug research information here during the process.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
I have examined the bug record, but there is still no new update yet. I suspect the WMI team may require more time to address it. If your requirement is urgent, I would recommend you to contact Microsoft PSS to request a hotfix regarding this bug. The bug ID is "Windows OS Bugs 1972337". Since this is a bug, the support case will be free.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
when I changed the image path back to the full length it origionally started at, the sc.exe process is functioning perfectly, this may not be an sc.exe problem at all.
ignore.. it appears that it had to be synced through the control groups before it would happen again.
16-Jul-08 01:45:34
when I changed the image path back to the full length it origionally started at, the sc.exe process is functioning perfectly, this may not be an sc.exe problem at all.
ignore.. it appears that it had to be synced through the control groups before it would happen again.
16-Jul-08 01:45:34
when I changed the image path back to the full length it origionally started at, the sc.exe process is functioning perfectly, this may not be an sc.exe problem at all.
|
