installing opengl32.dll in VirtualBox disables admin mode
gbburkhardt opened this issue · comments
I've installed mesa-18.1.0.600-1-sfx.exe using option 1 in 'systemwidedeploy.cmd' in VirtualBox 5.2.12 with guest Win10 Pro version 1803. If I try to start a command window using 'Run as Administrator', a error dialog pops up with "File System error (-1073741189)." Other attempts to perform actions requiring admin privileges result in the same error. I don't see this problem with VMware running a similar guest. I haven't found any explanation for what the error code means, nor any similar reports.
If this isn't the best forum to report this problem, please let me know. Thanks.
I have no idea what happened here, I never encountered this myself. My admin privileges request routine is based on the top answer of this stackoverflow question. Note that the elevation routine requires vbscript. I may change it to powershell at some point. Looking online it seams to be a file system or UAC settings corruption. It looks pretty bad, and may be just a coincidence it was triggered by the deployment tool.
Update: I found some questions on Microsoft answers where it was stated that upgrades from Windows 7 to Windows 10 are likely to cause this.
As far as I can tell, the deployment tool worked. My OpenGL application is picking up the installed DLL. The errors occur when admin elevation is needed after the deployment tool was run. This VM was built from Win 10 installation disks. I'll try installing the DLL without using the script, just following the operations manually. If that doesn't work, I'll probably try rebuilding the VM. Thanks.
So, with a fresh VM created directly from a Win10 distribution CD, and no other software installed except Guest Additions, installation of 'mesadrv.dll' and setting the registry using the deployment tool causes a slightly different error. This seems to be specific to VirtualBox it all seems to work in VMware. The same error occurs when trying to run 'regedit'.
The event log application log contains two errors:
(Error)
Faulting application name: consent.exe, version: 10.0.14393.0, time stamp: 0x57899acd
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.14393.0, time stamp: 0x57899a84
Exception code: 0xc000027b
Fault offset: 0x00000000006d622b
Faulting process id: 0xab0
Faulting application start time: 0x01d3fcf3a0fc3947
Faulting application path: C:\Windows\system32\consent.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: 97843f3e-37ef-4b00-b1c0-5481cb9fc67e
Faulting package full name:
Faulting package-relative application ID:
(Information)
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: consent.exe
P2: 10.0.14393.0
P3: 57899acd
P4: StackHash12_e72
P5: 0.0.0.0
P6: 00000000
P7: 80004005
P8: 0
P9:
P10:
Attached files:
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_consent.exe_6d377ae1ec6cc844fa98ea637eaffccf13313717_34efc27e_08ec3d69
Analysis symbol:
Rechecking for solution: 0
Report Id: 97843f3e-37ef-4b00-b1c0-5481cb9fc67e
Report Status: 4
Hashed bucket:
I also note that I don't see this by simply removing 'mesadrv.dll' from c:\Windows\System32. Also, after installing, "sfc /scannow" reports no errors.
I think I understand what happens here now. The chain of events that lead to that crash is as follows:
- Virtualbox tries to pass-through OpenGL from host, but it fails on your system, maybe you are affected by this as Virtualbox declares Windos 10 compatibility since version 5.0;
- If OpenGL support from host is too limited or the driver fails to load, Virtualbox tries OpenGL from guest directly;
- Virtualbox uses wined3d library to execute Direct3D on top of OpenGL implementation selected at previous steps;
- Windows uses Direct3D hardware acceleration for User Account Control if advertised by the GPU driver;
- For some reason the wined3d library built into the Virtualbox GPU driver is unable to use Mesa3D llvmpipe driver successfully to render the User Account Control dialog leading to that crash.
Workaround is easy, disable 3D acceleration in VM settings. You can also use DirectX Control Panel (dxcpl) if you have Windows SDK installed on guest to turn off 3D acceleration for C:\Windows\System32\consent.exe using Force WARP option,
This issue needs to be revisited after I take care of #8 as there may be a connection.
Brilliant! That worked - simply unchecking "Enable 3D acceleration" in the VM settings. Thank you very much!
I'll document this issue in the user guide as there is not much I can do about it.
Read further if you want learn about why Virtualbox Direct3D support is so bad.
Because Virtualbox uses wined3d without gallium nine state tracker for Direct3D8 and 9 in VMs, its performance is very poor, so poor that is often slower than Microsoft WARP Direct3D9 built into Windows 8 and above especially if the VM is running on budget class host making it mostly useless. Even on Windows 7 guest, Google Swiftshader may be faster. Google swiftshader stable release is an order of magnitude slower than WARP.
Because Virtualbox Direct3D performance is so bad that rendering without GPU is often faster, wined3d component doesn't get updated in timely manner and stays with known issues forever. On Windows 8 or newer you are better off without it.