Custom Query (16363 matches)
Results (1207 - 1209 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #18192 | duplicate | Windows 10 x64 VM does not start with more than 8 vCPUs and Hyper-V -> duplicate of #17898 | ||
| Description |
I have a request for a Rendering machine with 56 cores. VirtualBox does not start an Windows 10 x64 Pro for Workstations guest with more than 8 vCores and Hyper-V enabled. According to https://forums.virtualbox.org/viewtopic.php?t=87445 it is a very well known bug and not limited to Win10 Pro for Workstations soI'm surprised I could not find it here. The log always Shows the following lines: 00:00:04.614859 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffffc0000096 P2=0xfffff80360406fd9 P3=0x0 P4=0x0 00:05:36.462561 GUI: Request to close active machine-window. Host: Ubuntu 18.04.1 LTS Guest: Windows 10 Pro for Workstations x64 I also tried to start it with KVM. It works but has a terrible performance. |
|||
| #18187 | fixed | Mismatched pool allocation/free in VBoxGuest.sys in 6.0 RC1 => fixed in svn | ||
| Description |
VBoxGuest.sys calls This happens in rtR0InitNative, where RTR0DbgKrnlInfoOpen is called before g_pfnrtExAllocatePoolWithTag is initialized. Therefore the object will be allocated with ExAllocatePool (tracked by Windows as tag "None"). The RTR0DbgKrnlInfoRelease call that follows happens after g_pfnrtExFreePoolWithTag is initialized, however, and therefore causes a mismatch. This should result in a BAD_POOL_CALLER bug check when using a checked build of Windows. It also reproduces in ReactOS (downstream bug https://jira.reactos.org/browse/CORE-15446), and produces log output like the following: (ntoskrnl/mm/ARM3/expool.c:2530) Freeing pool - invalid tag specified: IPRT != None
*** Fatal System Error: 0x000000c2
(0x0000000A,0xB6B08BD8,0x656E6F4E,0x54525049)
[7h
Entered debugger on embedded INT3 at 0x0008:0x809543a4.
kdb:> bt
Eip:
<ntoskrnl.exe:1543a5 (:0 (RtlpBreakWithStatusInstruction))>
Frames:
<ntoskrnl.exe:8c47d (ntoskrnl/ke/bug.c:1100 (KeBugCheckWithTf))>
<ntoskrnl.exe:8ca54 (ntoskrnl/ke/bug.c:1456 (KeBugCheckEx))>
<ntoskrnl.exe:ab8c2 (ntoskrnl/mm/ARM3/expool.c:2531 (ExFreePoolWithTag))>
<VBoxGuest.sys:153f5 (src/VBox/Runtime/r0drv/nt/alloc-r0drv-nt.cpp:80 (rtR0MemFree))>
<VBoxGuest.sys:d496 (src/VBox/Runtime/r0drv/alloc-r0drv.cpp:108 (RTMemTmpFree))>
<VBoxGuest.sys:fd27 (src/VBox/Runtime/r0drv/nt/dbgkrnlinfo-r0drv-nt.cpp:594 (RTR0DbgKrnlInfoRelease))>
<VBoxGuest.sys:15e95 (src/VBox/Runtime/r0drv/nt/initterm-r0drv-nt.cpp:345 (rtR0InitNative))>
<VBoxGuest.sys:d29c (src/VBox/Runtime/r0drv/initterm-r0drv.cpp:88 (RTR0Init))>
<ntoskrnl.exe:63cd4 (ntoskrnl/io/iomgr/driver.c:1587 (IopCreateDriver))>
|
|||
| #18177 | fixed | GUI: Create new disk should round to sector size (divisible by 512) -> fixed in 6.0.6 | ||
| Description |
Create a new VM. When creating the matching VDI, the slider and the numeric control for the file size allow you to select any number. In many cases where a decimal number is used (27.87 GB for example), the VDI creation fails with:
But this can be confusing for a new user that doesn't know what 512 or sector stands for. It would be nice if the GUI would round the decimal number to the closest number that's divisible with 512. You could have it "stick" the values in the slider, and/or round them in the numeric control. |
|||

