Page 1 of 1

Options for VBoxSVC.exe RELEASE logging?

Posted: 13. Jan 2019, 18:05
by keyboarderror
Hi all, I’m experiencing VirtualBox 6.0 startup failure on Windows and after a whole week of trying I’m thinking of doing release logging for VBoxSVC, but I’m all new to the VBox world so I need your advice or suggestions.

On my 64-bit Win7SP1 I receive an E_NOINTERFACE (0x80004002) COM exception regarding IVirtualBox upon invoking the main GUI. In fact, it has been so ever since I first started trying it out using ver 5.1; I had relied on another machine with exactly the same hardware to run VirtualBox.

I can confidently conclude from my trials and errors that either the class factory for VBoxSVC (the VBox MAIN API??) did not actually create the VirtualBox instance--not necessarily a COM issue, or errors in the Proxy / Stub marshalling interface forbade it from returning correct pointers--surely a COM issue. More about my 'trials and errors' later.

And now, my questions regarding logging for IVirtualBox instantiation in VBoxSVC:
  1. Is COM component logging of VBoxSVC (BTW I assume VBoxSVC == VBOx Main API, is that right?) allowed in release logging? I am not in the position of building a Debug version anyway. Too complicated and don't have paid VS.
  2. How do VBox / IPRT logging differ? What is Sander / Bird logging? How is Log-level defined and used in VBox? Didn't find docs for them.
  3. Which logging groups and flags are recommended for my purpose? To be more precise, logging for (1) tracing the entire IVirtualBox instatiation process in the VBoxSVC class factory and (2) monitoring all QueryInterface calls on the ProxyStub marshalling interface on both C/S.
  4. how do the flags for logging groups differ from the VBOXSVC_RELEASE_LOG_FLAGS var? Where can I find enum for possible values of the latter?
  5. I notice quite a number of inadequately documented flags / options / semantics in the two header files mentioned in your online debugging doc, should I consider them for my purpose?
In case you ask: I don’t think studying the VBoxSVC source code is an efficient solution since it has to be very complex with a lot of references to make VBoxSVC work as the centre of the universe. Nevertheless, if you have a better solution than logging, just tell me.

BTW I do programming just for fun, although I do work with COM everyday to develop MS Office add-ins and write WinMgmt scripts. pls don’t bang me with too much technical details.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And now more on my 'trials and errors' mentioned above. Keep reading if you are in good mood.

The original error message from the GUI:
Failed to acquire the VirtualBox COM object.
Failed to instantiate CLSID_VirtualBox w/ IVirtualBox, but CLSID_VirtualBox w/ IUnknown works.
PSDispatch looks fine. Weird.
//Remarks: I've checked source code for VBoxC. This line simply means the PSDispatch class implemented in oleaut32.dll is not broken. Maybe I should re-reg oleaut32.dll to be safe? Re-reg that DLL itself is dangerous though...
Result Code: E_NOINTERFACE (0x80004002)
Component: VirtualBoxClientWrap
Interface: IVirtualBoxClient {d2937a8e-cb8d-4382-90ba-b7da78a74573}
Interesting findings of some of my experiments on my buggy machine
  1. On the functioning machine and my own machine, DLL calls on the VBoxSVC.exe are executed in exactly the same manner, except for a call by oleaut32.dll for RegOpenKeyW() in advapi32.dll on the functioning machine immediately before GUI appears: same number of calls, same modules involved and same functions requested, evidenced by monitoring GetProcAddress() in VBoxSVC.exe. Meanwhile, the same set of DLLs are loaded but the functioning machine has three or four more threads than my buggy one.
  2. VBoxSVC (and VBoxSDS) remains in memory once loaded if called using early bind. When using late bind, the server can gracefully self-destruct after timeout only if the IVirtualBox instantiation request originates from the user himself/herself, i.e. both CreateObject("VirtualBox.VirtualBox") and CreateObject("VirtualBox.VirtualBoxClient") would fail to get the IVirtualBox pointer but self-termination works for the former.
            note: The createLocalObject COM / XPCOM method in the source code would release object pointer if and only if instantiation is successful, which partially explains this, but only partially.
  3. Instantiation of IVirtualBox actually returns *IUnknown . If you try it with Windows scripting you’ll end up with *IUnknown encapsulated in the Variant COM data type (you can't assign *IUnknown to an Object var type): MsgBox TypeName(CreateObject("VirtualBox.VirtualBox")) 'returns Unknown, not Nothing or IVirtualBox.
  4. If you use OLEView (32/64) from WinSDK, you'll find IVirtualBox and IDispatch missing upon instantiation of the VirtualBox class, and VBoxSVC.exe becomes permanent resident in mem.
  5. VBoxSVC considers itself occupied and rejects OS shutdown attempts in WM_QUERYENDSESSION Window message ("has active connections"), although no IVirtualBox is created at all.
  6. FYI, certain versions of the Process Monitor from SysInternals would crash on my system without any error messages. I suspect this and VBoxSVC error is related, and further that I've got screwed up C++ redist packages on my OS but I'm not sure and I don't know how to check.
What I've tried
  • Consulting manual. Nothing directly relevant. Most people are finding bugs during VM runtime ...
  • Windows event viewer. Nothing helpful.
  • WinDBG on the release build. Nothing helpful except learning that thread naming is done by ostensibly throwing an exception with magic number error code.
  • Monitoring module loading. The ProxyStub marshalling component (VBoxProxyStub) is loaded in the server & client. Nothing erred.
  • Programmatically accessing IVirtualBox using VB, VBS. See findings.
  • Manually starting VBoxSVC and then the GUI. Didn't help.
  • Unreg, rereg of VBox COM components, including VBoxSVC.exe /UnReg | /Reg | /ReReg. Didn't help.
  • Windows Registry maintenance. Nothing weird reported by those reg cleaning tools.
  • Resetting network components using Netsh. Confirming running status of RPC- and DCOM-related services like SMB, Rpc Endpiont Mapper, LanmanServer, LanmanWorkstation, Browser, MSDTC (KtmRm is not started and I don't think it matters anyway). Removing WinPCAP. Didn't help.
  • Profiling with SysInternals’ Procmon and the famous Dependency Walker.
  • Reverting security, network, and group policy settings to default (as much as I can).
  • Trying out everything using the built-in Administrator account. Nothing helpful.