Custom Query (16363 matches)
Results (2413 - 2415 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #15490 | fixed | On Windows RS builds 14361 and higher hyper-v and vbox don't work due to hyperguard | ||
| Description |
Hyperguard (starting with TH2) blocks programs from scribbling over control registers like CR4. In RS1, Hyper-V opportunistically enables secure kernel which brings in Hyperguard when the Hyper-V role is enabled. VBox needs to do something here, detect an incompatible hypervisor and not bugcheck HyperGuard intercepts the write to CR4 and injects a #GP (here is the value VirtualBox tried to write: rax=0000000000000274). VirtualBox does not require VT-x to run 32-bit guests. In RS1, HyperGuard / secure kernel is always present when the hypervisor is present. That means that if a customer installs Hyper-V and VirtualBox, the machine will always bugcheck when the first VirtualBox VM is started. This was not the case in TH2. STACK_TEXT: ffffde00`9e2ac668 ffffde00`99dca712 : 00000000`00000010 fffff802`1eec16c6 00000000`00000000 ffff858f`1cfea1a0 : 0xffffde00`99dca890 ffffde00`9e2ac670 00000000`00000010 : fffff802`1eec16c6 00000000`00000000 ffff858f`1cfea1a0 00000000`0000639f : 0xffffde00`99dca712 ffffde00`9e2ac678 fffff802`1eec16c6 : 00000000`00000000 ffff858f`1cfea1a0 00000000`0000639f fffff802`1ef2aff0 : 0x10 ffffde00`9e2ac680 fffff802`1eec2ae8 : 00000000`c8077200 ffffde00`9e2acb80 00000000`0022821c ffff858f`20a02680 : VMMR0!VMMR0EntryFast+0xf96 ffffde00`9e2ac6e0 fffff802`1cb66250 : 00000000`00000000 fffff800`81896aa9 fffff6bf`fe4b27b8 ffff858f`1faedd00 : VMMR0!VMMR0EntryEx+0xe8 ffffde00`9e2ac750 fffff802`1cb74140 : ffff858f`00000000 00000000`00000030 00000000`00000030 00000000`00000000 : VBoxDrv!SUPR0PageFree+0x1e30 ffffde00`9e2ac7b0 fffff800`818c07de : fffff802`1cb73e70 00000000`0022821c 00000000`0531f9c8 ffffde00`00000030 : VBoxDrv!SUPR0SuspendVTxOnCpu+0x29f0 ffffde00`9e2ac850 fffff800`818bf9c6 : ffff858f`1faedd00 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x51e [d:\rs1\minkernel\ntos\io\iomgr\internal.c @ 10464] ffffde00`9e2aca20 fffff800`815e1193 : fffff6fb`7dafff90 fffff6fb`7dbed7f8 ffffc7cb`c9738199 00000000`00000000 : nt!NtDeviceIoControlFile+0x56 [d:\rs1\minkernel\ntos\io\iomgr\devctrl.c @ 110] ffffde00`9e2aca90 00007ffc`b7dc1344 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 [d:\rs1\minkernel\ntos\ke\amd64\trap.asm @ 2564] 00000000`0531f928 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffc`b7dc1344 |
|||
| #15488 | duplicate | IntegrityError: (1062, "Duplicate entry 'serge.kalmykov@gmail.com' for key 'PRIMARY | ||
| Description |
Trac detected an internal error: IntegrityError: (1062, "Duplicate entry 'serge.kalmykov@…' for key 'PRIMARY'") There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue. To that end, you could Create a ticket. The action that triggered the error was: POST: /login TracGuide — The Trac User and Administration Guide |
|||
| #15485 | invalid | beta 64bit load Version 5.1.0_BETA1 r107766 No more handles available | ||
| Description |
Running Android 4.4 VM from 5.0.20 fails with "No more handles available" on Windows 10 x64 notebook. Logs and sysinfo attached |
|||

