Windows 11 build 25987 (Canary) - VirtulaBox not working

[Ang_elo]

Hi, just for letting you now, VirtualBox vers. 6.1.48 r159471 is not working on Windows 11 Build 25987 on Canary Channel, and yes, I know that it's not supported, btw:

The error is (Windows MessageBox):
Unknown rc=-3748 (Unknown Status -3748 (Oxfffffl 5c)) (rc=-3748)
Make sure the kernel module has been loaded successfully.
where: supiibOslnit what: 3 VERR SUPDRV NOT BUDDING VM PROCESS 1
(-3748) - The process trying to open VBoxDrv is not a budding VM process (1).

and then:
The virtual machine 'Windows 10' has terminated unexpectedly during startup with exit code 1 (0x1). More details may be available in 'E:\My Virtual Machines\VMs\Clients\Windows 10\Logs\VBoxHardening.log'.
Result Code:
E_FAIL (0x80004005)
Component:
MachineWrap
Interface:
IMachine {85632c68-b5bb-4316-a900-5eb28d3413df}


Partial VBoxHardening.log (other logs are not produced):
{ mod edit - deleted partial pasted hardening log}

Best Regards,
Angelo

[mpack]

Please don't spray text all over us, use zipped attachments.

[Ang_elo]

Sorry for that, you'll find the log attached and the error message as well.
Angelo

[mpack]

The log shows a number of certification problems on this host PC. The following is only a sample.

28a8.3c70: \SystemRoot\System32\ntdll.dll: Signature #1/1: VERR_CR_X509_CPV_NOT_VALID_AT_TIME for 0x69397ec4; retrying against current time: 0x65439d87.
28a8.3c70: '\Device\HarddiskVolume5\Windows\System32\ntdll.dll' has no imports
28a8.3c70: \Device\HarddiskVolume5\Windows\System32\kernel32.dll: Signature #1/1: VERR_CR_X509_CPV_NOT_VALID_AT_TIME for 0xef1f5e11; retrying against current time: 0x65439d87.
28a8.3c70: \Device\HarddiskVolume5\Windows\System32\KernelBase.dll: Signature #1/1: VERR_CR_X509_CPV_NOT_VALID_AT_TIME for 0x7c9ce935; retrying against current time: 0x65439d87.
28a8.3c70: \Device\HarddiskVolume5\Windows\System32\apphelp.dll: Signature #1/1: VERR_CR_X509_CPV_NOT_VALID_AT_TIME for 0x3f88f3ba; retrying against current time: 0x65439d87.
28a8.3c70: apphelp.dll: Differences in section #3 (.rdata) between file and memory:
28a8.3c70: 00007ff85c18f3b0 / 0x005f3b0: 80 != 10
28a8.3c70: 00007ff85c18f3b1 / 0x005f3b1: a3 != 4c
28a8.3c70: 00007ff85c18f3b2 / 0x005f3b2: 77 != f1

I'd say you've either been hacked, or you have some third party (non MS) system level software that VirtualBox takes exception to. However VirtualBox does not identify the culprit.

[BrotherManEd]

Having the same issue here with 7.0.10 and 7.0.12

[BrotherManEd]

I read elsewhere that the Microsoft Windows Insider Program root certificate may be expired. Checking myself to see if the update overnight did this. May have to revert system to previous backup.

[panagios]

same thing here at two different PCs. Reverting before upgrade didn't solve the problem. trying everything without success...

[mpack]

Trying everything - except identifying the third party AV crap that causes the interference?

An expired certificate will not, AFAIK, result in those "differences between file and memory" stuff I quoted from the log. Only injected code will do that, exactly the stuff that hardening is designed to detect.

And if you don't have those symptoms then your problem is not the same as the OP, so don't post in this topic.

[panagios]

Trying everything - except identifying the third party AV crap that causes the interference?

An expired certificate will not, AFAIK, result in those "differences between file and memory" stuff I quoted from the log. Only injected code will do that, exactly the stuff that hardening is designed to detect.

And if you don't have those symptoms then your problem is not the same as the OP, so don't post in this topic.

well...
i, obviously, thought that the problem may be elsewhere but after having the same 3748 error in a third pc and the only common thing is 25987 build installed yesterday, i\ve started to become real suspicious that it has to do something with the recent upgrade

[KamilCh]

Same here after upgrade to 25987

[dc8]

Hey mpack, bud. Let's slow the roll a bit here. There's no need to get people panicked that they've been hacked or they're otherwise victims of code injection.

Canary is the most bleeding edge, marginally tested build of Windows there is. (MSFT's description of Canary follows.) Stuff like this happens. It's already being tracked in MSFT's feedback tool here, with a link to this thread: https://www[dot]microsoft[dot]com/en-us/windowsinsider/feedbackhub/fb?contextid=156&feedbackid=1dd133e9-e903-42fc-8db8-9ce9c280bc43&form=1

It's either:

a) A problem with the current build that MSFT will fix in an upcoming build.
b) A change that will break 3rd party software, like VBox, in an upcoming stable release of Windows.

In the first case, the solution is to wait for the next build. In the second case, this is an early indicator for the VBox team that there's a breaking change with one of their host platforms on the way.

The new Canary Channel is going to be the place to preview platform changes that require longer-lead time before getting released to customers. Some examples of this include major changes to the Windows kernel, new APIs, etc. This is very similar to what we’ve been flighting to the Dev Channel in the past. And like the Dev Channel, some of the changes we try out in the Canary Channel will never ship, and others could show up in future Windows releases when they’re ready.

The builds released to the Canary Channel will have higher build numbers than the Dev, Beta, and Release Preview Channels – starting with 25000 series builds. Insiders previously in the Dev Channel were already receiving these builds and to ensure they continue to receive new updates going forward, we will be moving these Insiders to the Canary Channel starting today. Insiders moved to the Canary Channel will receive notifications of this migration in the OS and via email and can take steps to clean install to pick a different channel if they choose. See the Switching Channels section below for more details.

This also includes commercial devices configured for the Dev Channel on 25000 series builds managed by IT administrators via Windows Update for Business policy, Microsoft Intune or through Group Policy. Please note, the changes to the policy to enable customers to opt-into the new Canary Channel via policy will be coming soon.

The builds that will be flighted to the Canary Channel will be “hot off the presses,” flighting very soon after they are built, which means very little validation and documentation will be done before they are offered to Insiders. These builds could include major issues that could result in not being able to use your PC correctly or even in some rare cases require you to reinstall Windows. We will offer limited documentation for the Canary Channel, but we will not publish a blog post for every flight – only when new features are available in a build. We will continue to provide blog posts for Dev, Beta, and Release Preview releases like we do normally.

Our Canary Channel won’t receive daily builds; however, we may ramp up releasing builds more frequently in the future.

[mpack]

I am interested in evidence, i.e. stuff I see in a log. I am not interested in assertions. If you have a better explanation for the content of the previous log then don't stand on ceremony: tell us.

AFAIK, the log is not explained by having a prerelease Windows - I already said this.

[dc8]

I’m not looking for a fight. I’m just trying to add some context and hopefully moderate the tone a bit.

I’m also not arguing with what you’ve spotted in the log files. Typically, on production systems, I’d even agree with your assessment.

But here we have an issue that’s only been reported on hosts running this specific Canary build of Windows on the same day it was released. It doesn’t make much logical sense that several people, all running the same, fairly rare OS, who also happen to be VBox users, would also go out and install a new AV or just happens to get hacked right around the same time as a new build came out. It’d be even more rare that no one else running a production (or even beta or dev) build of Windows is reporting the same thing.

Speaking for me only, I was working in VBox, had to shut down my guest OS, saw that there was a Windows update, installed it, rebooted, and immediately tried to go back to work in VBox. There wasn’t anything new to cause the problem other than the update.

It’s also very interesting that the logs are reporting the difference in the .rdata section of the dlls. While those typically wouldn’t change after loading, they’re also not the .text section, which is where code is stored. This likely isn’t something using detours to modify the function of loaded code, like malware, AVs, and game mods would.

My best guess (and, admittedly, this is a guess) is MSFT flighted a build where they left telemetry or something else associated with their internal automated validation enabled in this build.

Again, I think this is currently a non-issue as far as VBox is concerned and that the root cause is very probably moot. This is an issue that impacts a very tiny subset of users, likely for a short period of time, who are running an OS that they should expect to break.

[MadDogBlack]

I'm getting the same error so MSoft has apparently messed up something.
Same Canary build
Going to do a rollback...this has already been reported in MSoft feedback system.

[fth0]

The error VERR_SUPDRV_NOT_BUDDING_VM_PROCESS_1 means that some software is intercepting the opening of the VBoxSup.sys kernel driver. This could be a new legitimate Windows function as well as AV software or malware. This error is accompanied by a STATUS_ACCESS_VIOLATION error in ntdll.dll (KiUserExceptionDispatcher).

---

It’s also very interesting that the logs are reporting the difference in the .rdata section of the dlls. While those typically wouldn’t change after loading, they’re also not the .text section, which is where code is stored. This likely isn’t something using detours to modify the function of loaded code [...]

The first set of differences are 8 function pointers in the .rdata section of apphelp.dll, which originally point into the .text segment of apphelp.dll and were changed to point into the .text segment of ntdll.dll. I've seen such redirections in the past. without being a problem, and VirtualBox successfully replaced the section.

The second set of differences are in the .mrdata section of ntdll.dll. The original zero values were replaced ... Learned something new: I haven't heard about a "mutable read-only data" section before. Interesting stuff for hackers!