Windows 7 XP Mode – Auto Publish ‘Not Available’

Hello All, Ron Riddle here again to share another mystery relating to the XP Mode Auto Publish feature for Windows 7 that had an unexpected root cause.  As you may know, the Auto Publish feature allows applications installed within the guest to be automagically available from the start menu of the Windows 7 host.  Of course, one requirement for this to work properly is that the feature must be enabled; however, I have encountered two such instances where the feature is listed as ‘Not Available’ within the Virtual PC Settings UI once the guest is started.




Debugging the Issue


The Virtual PC Integration Components Services Application (1-vmsrvc) service, which runs within a vmsrvc.exe instance on the guest, decides whether the Auto Publish feature should be enabled.  For non-Windows 7 guests, the first thing 1-vmsrvc does is issue a WMI query to determine whether KB961742 (for an XP guest) or KB961741 (for a Vista guest), which provide Remote Applications Integrated Locally (RAIL) support, have been applied.


Root Cause Analysis


Before we issue the WMI query, we must first activate the CLSID_WbemLevel1Login component.  Here’s an excerpt below:


0:009> k

ChildEBP RetAddr 

00b1f730 74ef186e wbemprox!CDCOMTrans::DoActualCCI+0x3d

00b1f774 74ef15db wbemprox!CDCOMTrans::DoCCI+0x12d

00b1f830 74ef17e4 wbemprox!CDCOMTrans::DoActualConnection+0x25c

00b1f85c 74ef1ee1 wbemprox!CDCOMTrans::DoConnection+0x25

00b1f89c 01018283 wbemprox!CLocator::ConnectServer+0x7c

00b1fae8 010182da vmsrvc!VPCRAILUpdates::Connect+0xa8

00b1faf4 0101842b vmsrvc!VPCRAILUpdates::QueryInstalledFixes+0xb

00b1fe34 0100b61f vmsrvc!VPCRAILUpdates::CheckIfUpdatesArePresent+0x91

00b1ffb4 7c80b729 vmsrvc!Win32VPCAppPublisherService::AllowListNotificationThreadProc+0x90

00b1ffec 00000000 kernel32!BaseThreadStart+0x37


However, I noticed that the activation attempt failed with WBEM_E_CRITICAL_ERROR(0x8004100a).


0:009> r eax



So, I proceeded to debug the activation attempt from within the Windows Management Instrumentation(winmgmt) service, since it provides the class factory for this component.  Notice the call to LoadLibraryExW passing a relative path for the lpFileName parameter.  This means that a search strategy must be applied which leverages the PATH environment variable.


0:002> k

ChildEBP RetAddr             

0086f438 594976e2 kernel32!LoadLibraryExW

0086f494 7751d8a7 wmisvc!CForwardFactory::CreateInstance+0xf8

0086f4b8 7751daac ole32!GetInstanceHelperMulti+0x20

0086f578 77e799f4 ole32!CObjServer::CreateInstance+0x251

0086f59c 77ef421a RPCRT4!Invoke+0x30

0086f9a8 77ef4bf3 RPCRT4!NdrStubCall2+0x297

0086fa00 77600c15 RPCRT4!CStdStubBuffer_Invoke+0xc6

0086fa40 77600bbf ole32!SyncStubInvoke+0x33

0086fa88 7752ad31 ole32!StubInvoke+0xa7

0086fb60 7752ac56 ole32!CCtxComChnl::ContextInvoke+0xe3

0086fb7c 776007f5 ole32!MTAInvoke+0x1a

0086fbac 77602df3 ole32!AppInvoke+0x9c

0086fc80 77600715 ole32!ComInvokeWithLockAndIPID+0x2c2

0086fccc 77e794bd ole32!ThreadInvoke+0x1cd

0086fd00 77e79422 RPCRT4!DispatchToStubInC+0x38

0086fd54 77e7934e RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x113

0086fd78 77e8a384 RPCRT4!RPC_INTERFACE::DispatchToStub+0x84

0086fdb8 77e8a3c5 RPCRT4!RPC_INTERFACE::DispatchToStubWithObject+0xc0

0086fdf8 77e7bcc1 RPCRT4!LRPC_SCALL::DealWithRequestMessage+0x2cd

0086fe1c 77e7bc05 RPCRT4!LRPC_ADDRESS::DealWithLRPCRequest+0x16d


0:002> du poi(esp+4)

59491668  "wbemcore.dll"


Surprisingly, I found that the requested library could not be found using the standard search strategy.


0:002> !gle

LastErrorValue: (Win32) 0x7e (126) - The specified module could not be found.

LastStatusValue: (NTSTATUS) 0xc0000135 - {Unable To Locate Component}  This application has failed to start because %hs was not found. Re-installing the application may fix this problem.


I then decided to enable boot logging within the Process Monitor tool to catch a glimpse into why the load for wbemcore.dll was failing.  Here’s an excerpt from the Process Monitor log:


8:18:11.1652951 PM      svchost2.exe      1628  QueryOpen   C:\WINDOWS\system32\%SystemRoot%\system32\wbemcore.dll  PATH NOT FOUND    

8:18:11.1653627 PM      svchost2.exe      1628  QueryOpen   C:\WINDOWS\system32\%SystemRoot%\wbemcore.dll        PATH NOT FOUND 

8:18:11.1654161 PM      svchost2.exe      1628  QueryOpen   C:\WINDOWS\system32\%SystemRoot%\System32\Wbem\wbemcore.dll  PATH NOT FOUND     


At this point, it became clear to me that something must be wrong with the PATH environment variable configuration because the SystemRoot environment variable was not being properly expanded.  Sure enough, the registry showed that the Path value was of type REG_SZ rather than REG_EXPAND_SZ.




Once I saved off the data for the Path value and recreated it specifying the proper type(REG_EXPAND_SZ), the issue was resolved!


Sidenote on the Debugging Strategy


I chose to debug the services by attaching ntsd.exe and redirecting the session to the kernel debugger.  Alternatively, I could have chosen to use a remote debugging session since it’s much more natural than redirecting to the kernel debugger, in my opinion.  However, this issue was further complicated by the fact that introducing a debugger in the mix had potential to change the timing enough such that I struggled to reproduce the issue using a remote session.  The reason for this is that if we slow down the 1-vmsrvc execution enough, the winmgmt service itself will attempt to load wbemcore.dll, albeit through an activation request where an absolute path is specified, thereby avoiding application of a search strategy, which will succeed.  Thus, when 1-vmsrvc attempts to activate CLSID_WbemLevel1Login, it will now succeed because wbemcore.dll is already loaded and the Auto Publish feature will now be ‘Enabled’!




I leveraged the Image File Execution Options key, creating a new entry for vmsrvc.exe and configuring the Debugger value with the following command line:


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\vmsrvc.exe]

"Debugger"="c:\\debuggers\\ntsd.exe -d -y srv*c:\\vmsrvc -c \"bu vmsrvc!Win32VPCAppPublisherService::AllowListNotificationThreadProc;bu wbemprox!CDCOMTrans::DoActualCCI;g\""


I also isolated the winmgmt service into its own svchost.exe, copied %systemroot%\system32\svchost.exe to %systemroot%\system32\svchost2.exe, and then created a new key for svchost2.exe with the following command line:


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\svchost2.exe]

"Debugger"="c:\\debuggers\\ntsd.exe -d -y srv*c:\\winmgmt -c \"bu wmisvc!CForwardFactory::CreateInstance;g\""


Although redirecting ntsd.exe to the kernel debugger was cumbersome from a usability perspective, I found the ability to debug both processes from a central facility very appealing and worthwhile.




For issues like these that ultimately resolve to a misconfiguration of the OS, I can’t help but think how unfortunate it was that I didn’t stumble onto root cause sooner via the routine task of launching some executable from a command shell.  Surely this would have been a red flag and could have saved me a lot of time debugging!




While this was a rather extreme example of how a misconfiguration of the OS can affect other seemingly unrelated parts such as the Auto Publish feature of XP Mode, the take-away here is when you detect that the Auto Publish feature is ‘Not Available’, you should begin with standard WMI troubleshooting; and, as we’ve just seen here, a quick sanity check of the environment might not be a bad idea either! 🙂


Until next time, happy debugging!

Comments (3)

  1. Miro says:

    Hi, this may be a lame question, but based on the output provided, how did you found out that the CLSID_WbemLevel1Login activation attempt return value is stored in eax and LoadLibraryExW stores the characters in poi(esp+4)? Have you unassembled the functions? Thanks.

    [On x86 systems, the return value is always stored in the EAX register.  Also, if you reference the documentation for LoadLibraryEx( , you’ll find that the first parameter is lpFileName.  In this case, I knew that I was at the first instruction of the LoadLibraryExW function and that the only value that had been pushed on the stack thus far (via the ESP register) was the calling function’s return address.  Therefore, I was able to use the poi syntax to dereference the expression (esp+4), which accounts for the 4-byte return address and gets me to the location of the first parameter, lpFileName.]

  2. Marc Sherman says:

    Was isolating the winmgmt service as simple as using sc.exe to change the binary path to svchost2.exe?




    [Sc.exe can break out an svchost to it's own process.  You can also manually configure this using the registry.]

  3. Allan Michaels says:

    After installing SAP Business One (Release 2004 A) and its FSE addons, I had this exact problem.  I fought it for a long time before finding this explanation.  I finally put 2 and 2 together when at a command prompt, wuauclt.exe /detectnow couldn't be found, even with %SystemRoot%system32 in the path.  Thank you very much and hopefully this post helps anyone else fighting older version of SAP/FSE on XP Mode.


    [Thank you for your feedback.  We are glad to hear this article was helpful.]

Skip to main content