Opened 6 weeks ago
Last modified 5 weeks ago
#22363 assigned defect
Windows Guest Machine fails to start when recording is enabled in Display Settings
Reported by: | tempdrive | Owned by: | pentagonik |
---|---|---|---|
Component: | other | Version: | VirtualBox-7.1.6 |
Keywords: | Screen Recording | Cc: | tempdrive |
Guest type: | Windows | Host type: | Windows |
Description
I was trying to use the screen recording functionality with the intent of creating a bug report with VirtualBox 7.1.7-168159, the latest available test build. When I tried to start the machine after selecting "Enable Recording" under Display Settings, the machine was terminated with invalid memory address references. Upon checking the Hardening.log, I have discovered that the program was trying to load "dxgi.dll" from "C:\Windows\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_7bb1fa07ea2dce86", however as far as I could verify, (at least) the latest Intel drivers do not have this file included, but it does exist in System32 folder, and even the logfile is referencing it. I managed to copy this file into the target directory, which did make this particular error disappear from the log, but the same error message is displayed upon trying to start the VM, which again results in termination of the process. Trying to fiddle around with the recording settings did not change anything.
There are 2 sets of log files, the first one has the reference to the missing "dxgi.dll" from the Intel driver folder. The second set of log files is after the file was copied.
It is important to note that while the machine cannot be started with screen recording enabled, I was able to start the recording from the menus/bottom icons once the machine was online. In this case, however, the settings cannot be changed.
Again, I was trying to use this functionality to create (an other) bug report, and once I managed to get it work, the quality and the performance of the recording was sadly unacceptable. With the recording on, the performance of the machine was terrible, and the output file quality as well due to having teared screen as a side effect of the lagging. I did increase the quality to the maximum with no audio recording, and the machine runs on an SSD drive with this option reflected for the attached disk. The output was something that we could experience 2 decades ago on live systems. Eventually I switched to external application to create a video, which did produce a larger file (about 5 times the size) but with outstanding quality.
Just one more remark: for the screen recording the screen size to be recorded needs to be to pre-selected, which absolutely does not make any sense with fixed sizes when the window is stretchable. The custom setting should be at least adapting to the size automatically (recorded as sized). Alternatively you could go for the maximum host screen resolution and cover the irrelevant parts as blanks. The external software seemed to be capable of tracking the window size as far as I could tell, or something similar that I just described as desired behavior, so the software that runs the machines should not be having problems with locking on to the process rather than irrelevant fixed sizes.
Please try to fix as many things as possible. At least "dxgi.dll" should be managed accordingly, but there is certainly many opportunities to improve this this functionality in my opinion.
Attachments (2)
Change History (4)
by , 6 weeks ago
Attachment: | 1_screen_recording_logs.zip added |
---|
by , 6 weeks ago
Attachment: | 2_screen_recording_logs.zip added |
---|
comment:1 by , 5 weeks ago
comment:2 by , 5 weeks ago
Owner: | set to |
---|---|
Status: | new → assigned |
Thanks for the logs, I'll have a peek.