[GA] Regression: We still suffer the black screen video driver bug under Windows 2003, Windows XP 64 bits, ReactOS, etc.

[Julen Urizar Compains]

Affected vbox versions: From VirtualBox-6.1-6.1.44_156814 to 7.0_7.0.14-161095 current main branch.

Part of the software affected: VBox Guest Additions video for Windows NT based systems (that are not Windows XP 32 bits).

This is a regression. Affected since 6.1 version, concretely after the commit "(pending to investigate the commit number that caused the bug)".

Configuration of the VM: VBoxVGA, with 18 MB of Video RAM (can be switched to whatever, the resultant is the same failure). VBox guest additions installed. My host is a Debian, but this is reproducible even on Windows.

It is another instance of the bug (sorry if it's a duplication) https://www.virtualbox.org/ticket/21600 . I am not sure why, but the developers have fixed the Windows XP 32 bits, but not the rest of the Windows NT Systems, so Windows 2003 (x86 or x64), ReactOS x86 and x64, Windows XP 64 bits, Windows Vista, etc, seems affected with this bug.

I can provide vbox.log for every VM I have. Let me send it at least the Windows 2003 SP2.

We are aware of that in the ReactOS community, because we still suffer the bug. Somebody tried to make a workaround to force the VGA init, but it shouldn't be in that way. Should be the way it was.

Temporary workaround: Use the VBoxGuestAdditions_6.1.34.iso from older builds. Drivers will just work.

Related links: WinXP 32 bits fixed. Why not the rest? ​https://forums.virtualbox.org/viewtopic.php?f=2&t=109196#p535394 Windows 2003 x64 still affected: ​https://forums.virtualbox.org/viewtopic.php?t=110806 ReactOS report bug: (Under ReactOS, it BSODs) ​https://jira.reactos.org/browse/CORE-19224

[Julen Urizar Compains]

Windows 2003 - VBox GA video bug

[Klaus Espenlaub]

Can't understand why you think there was ever an issue with 64-bit Windows versions. For those there should've been no change (just the 32-bit ones tripped over being qualified as NTx86).

In the end it could be that more 32-bit Windows versions would need to use the "old style INF" but that would not cure any problem with 64-bit.

The change which caused the regression with 32-bit Windows is https://www.virtualbox.org/changeset/98308/vbox/trunk/ - and no, we didn't make this change because it "looks nice" but because it's what Microsoft's InfVerif.exe started requiring suddenly for 32-bit Windows 10. Without the change we wouldn't get the 32-bit variant of the drivers through Attestation Signing any more.

[Julen Urizar Compains]

Hi Klaus, I have here two VMs: One with Windows XP 64 bits and one with Windows 2003 x86 (32 bits), and moreover dozens of ReactOS vms. Both are failing with the newer version of the drivers. The version of the video drivers from 6.1.42 just worked there (and I can just manually install it as a workaround).

I don't think anything. If you need more reports, just ask me to do. I can test whatever Windows version is caused regression from the past to the current last one if you need it. With ReactOS too.

I know you didn't do this because you want it to look nicer or whatever, I only want the thing to work as it did. I only want this (I love to use VirtualBox in my Debian). If you need more tests made by me, just ask, if you need me to point something in my vm or send you my vm, just ask. I am open to offers.

Replying to Klaus Espenlaub:

Can't understand why you think there was ever an issue with 64-bit Windows versions. For those there should've been no change (just the 32-bit ones tripped over being qualified as NTx86).

In the end it could be that more 32-bit Windows versions would need to use the "old style INF" but that would not cure any problem with 64-bit.

The change which caused the regression with 32-bit Windows is https://www.virtualbox.org/changeset/98308/vbox/trunk/ - and no, we didn't make this change because it "looks nice" but because it's what Microsoft's InfVerif.exe started requiring suddenly for 32-bit Windows 10. Without the change we wouldn't get the 32-bit variant of the drivers through Attestation Signing any more.

[javispedro]

I have reproduced the issue with 64-bit XP . It seems to also require the "old style INF" changes that 32-bit XP requires. For me at least Vista and later (32 AND 64) are fine with the "new style INF".

In fact, I patched the VBoxVideo.inf (from the 7.0.14 64-bit additions) to be more like the "old style INF" and only then it works with 64-bit XP.

The only change required to make the .inf work is to rename the [VBoxVideo.SoftwareSettings] section into [VBoxVideo_Install.SoftwareSettings] , and the same for OpenGLSoftwareSettings. No other change is required. See attached.

This seems to agree with the diagnosis from the ReactOS. The MS documentation also says that SoftwareSettings is supposed to be "DDInstall.SoftwareSettings" (i.e. per device, which in this case is "VBoxVideo_Install", rather than per-manufacturer "VBoxVideo"). So to me the "new style INF" looks wrong here.

However, I can't understand why the "new style .inf" works on 64-bit Vista. Maybe MS at some point added a compatibility shim that also loads per-manufacturer SoftwareSettings sections ? Who knows.

In any case: XP/w2003 64-bit versions also need a "old style INF", but I think this is just to fix this .SoftwareSettings issue (rather than due to XP not being able to understand 'NTx86' or commas or anything like that).

I guess very likely that if we were to fix the .SoftwareSettings issue in the "new style INFs" then XP (both 32 & 64) could go back to using the "new style INF". EDIT: Confirming: 32-bit XP can understand the "new style INF" just fine, but only if I rename the .SoftwareSettings section to VBoxVideo_Install.SoftwareSettings .

[Klaus Espenlaub]

Thanks a lot for your detailed analysis. Maybe the root of the issue is a misunderstanding on our end related to the naming of the .SoftwareSettings section.

However, I can't see why renaming the section magically makes things work. Nothing refers to VBoxVideo_Install. How I'm understanding Microsoft's docs about INF files is that the [Manufacturer] section points at the [Model] section and the stuff there names the 'DDInstall' section which in our context is VBoxVideo. Not magically VBoxVideo_Install.

Therefore I'm not following why a one line change is supposedly fixing the issue.

You hint at some information in the ReactOS ticket which I wasn't able to spot, but I admit that I didn't look at absolutely every link. Maybe I missed something enlightening there.

Either way: I'm open for discussing how the final INF file should look from your perspective, because that might shed some more light on the topic, and maybe (eventually) leads towards an opportunity to create both 'old style' and 'new style' from one template, or even unify them to some extent.

[javispedro]

I'm a bit confused since both me and the ReactOS ticket see this exactly as the opposite as you described. For me the [Model] section clearly points to VBoxVideo_Install so the "magical" jump is how VBoxVideo.SoftwareSettings (w/o _Install) ends up being referenced. This is what is pointed in the ReactOS ticket: ​https://github.com/reactos/reactos/pull/6026#issuecomment-1823123671 ( " The section, VBoxVideo.SoftwareSettings is never referenced.")

Let me show what I see. For simplicity I'm using the .inf files that are built for x86.

"Old style INF" / aka "VBoxVideoEarlyNT.inf"

; VirtualBox Video miniport driver, Windows 2000 and NT4 edition.
...
[Manufacturer]
%ORACLE%=Model
...
[Model]
%VBoxVideo.SvcDesc% = VBoxVideo, PCI\VEN_80EE&DEV_BEEF
...
[VBoxVideo.SoftwareSettings]
AddReg = vboxvideo_SoftwareDeviceSettings

Here, Model = Model (confusingly), DDInstall = VBoxVideo, so VBoxVideo.SoftwareSettings is referenced. The old style INF, therefore, works under XP32 (& 64).

"New style INF" / VBoxVideo.inf

; VirtualBox Video miniport driver, XP+ edition.
...
[Manufacturer]
%ORACLE%=VBoxVideo,NTx86
...
[VBoxVideo.NTx86]
%VBoxVideo.SvcDesc% = VBoxVideo_Install, PCI\VEN_80EE&DEV_BEEF
...
[VBoxVideo.SoftwareSettings]
AddReg = vboxvideo_SoftwareDeviceSettings

Here, Model = VBoxVideo, DDInstall = VBoxVideo_Install, so VBoxVideo.SoftwareSettings is NOT referenced. What would be referenced is "VBoxVideo_Install.SoftwareSettings", but it does not exist. Therefore, the new style INF fails under XP32 (& 64).

(Note that since 7.0.10, guest additions installer redirects XP32 guests towards the old-style INF -- but not XP64 or w2k3 guests)

"Fixed" new-style INF

...
[Manufacturer]
%ORACLE%=VBoxVideo,NTx86
...
[VBoxVideo.NTx86]
%VBoxVideo.SvcDesc% = VBoxVideo_Install, PCI\VEN_80EE&DEV_BEEF
...
[VBoxVideo_Install.SoftwareSettings]
AddReg = vboxvideo_SoftwareDeviceSettings

I just changed the title of the .SoftwareSettings section. This is enough to make this .inf file work at least in XP32 as I mentioned in the update to my previous post. I will be attaching this file under the "VBoxVideo32.inf" name.

[javispedro]

patched 32-bit "new style" .inf

[Klaus Espenlaub]

Must have confused myself when digging through the history of those INF files. Whatever. Makes sense now and any 7.0 Guest Additions test builds with revision 161958 or higher will have this fixed. Make sure you pick the separate GA ISO file and use it as a "normal DVD image". Not sure if the ISO file included in the normal packages is recent enough.

[Julen Urizar Compains]

Windows XP x64 fixed

[Julen Urizar Compains]

Windows 2003 - fixed

[Julen Urizar Compains]

ReactOS x86 Fixed

[Julen Urizar Compains]

Thanks you, thanks you really much for your fast bug fixing. At least, solved in my 3 testing fields right now with the 161959 version and my typical VM.

And the most important for me: ReactOS. :D So thanks you really much.

I wonder if any older/weird Windows versions suffered it, I hope it won't.

Post-ticket: Would it be ported back to the VBox GA 6 version? I know that is unmaintained or unsupported right now and maybe won't be sensible for the people that uses that old version. But if it would be possible, would be nice.

[Klaus Espenlaub]

No one at Oracle will do anything with the 6.1 branch any more (all builds of this branch have been disabled weeks ago). Applying r103601 can be done by any dev, but I guess very few people on this planet have the knowledge (and certs/keys) to create a properly signed build. Better solution should be using the 7.0 Guest additions...