0xc0000005 Access Violation in VBoxSVC.exe during Delete Snapshot operation

[Bob Kosch]

Happens with much less frequency than 4.1.0, where it was an everyday occurrence, but when VBoxSVC crashes in the middle of collapsing the state of the virtual machine, it invariably leaves orphaned files, resulting in the usual (2)-child hard stalemate.

Host is Windows 7 x64 SP1.

[ddn]

i have exactly the same!

[Bob Kosch]

Another occurrence when reverting the current machine state to a previous snapshot.

This also results in the snapshot forking into multiple vdi files, thus being rendered undeletable.

The developers need to find their own ways of isolating instabilities in their hypervisor by exhaustive automated software testing, not insisting that end-users provide a precise sequence of replication steps, an approach which is a total dead-end, thus doomed to failure.

We are not resources for regression-testing VirtualBox, we need to concentrate on actually using it, confining our testing to the virtual environments themselves, not the virtualization environment.

Log Name: Application

Source: Application Error

Date: 9/17/2011 7:36:25 PM

Event ID: 1000

Task Category: (100)

Level: Error

Keywords: Classic

User: N/A

Computer: wrkosch

Description:

Faulting application name: VBoxSVC.exe, version: 4.1.2.0, time stamp: 0x4e4911e8

Faulting module name: VBoxSVC.exe, version: 4.1.2.0, time stamp: 0x4e4911e8

Exception code: 0xc0000005

Fault offset: 0x00000000001937a9

Faulting process id: 0x105c

Faulting application start time: 0x01cc7580a91ebead

Faulting application path: E:\Program Files\Oracle\VirtualBox\VBoxSVC.exe

Faulting module path: E:\Program Files\Oracle\VirtualBox\VBoxSVC.exe

Report Id: 004cc6e8-e19f-11e0-8c17-005056c00008

[blast]

Reproduces in VirtualBox 4.1.10, while trying to delete a snapshot via VBoxManage.exe. Running Windows XP x86 SP3 guest on Windows 7 x64 SP1 host.

---

Faulting application name: VBoxSVC.exe, version: 4.1.10.0, time stamp: 0x4f60d450

Faulting module name: VBoxSVC.exe, version: 4.1.10.0, time stamp: 0x4f60d450

Exception code: 0xc0000005

Fault offset: 0x000000000014a9c4

...

Faulting application path: C:\Program Files\Oracle\VirtualBox\VBoxSVC.exe

Faulting module path: C:\Program Files\Oracle\VirtualBox\VBoxSVC.exe

[blast]

Call stack on ver 4.1.10:

---

# Child-SP RetAddr Call Site

00 0000000003d8fa90 000000014019814a VBoxSVC+0x14a9c4 ( possibly replaceMachineId.isEmpty() )

01 0000000003d8fac0 000000014018c6b4 VBoxSVC+0x19814a ( void SessionMachine::deleteSnapshotHandler(DeleteSnapshotTask &aTask) )

02 0000000003d8fe60 000000000046af0f VBoxSVC+0x18c6b4

03 0000000003d8fea0 00000000004be11a VBoxRT!RTThreadFromNative+0x54f

04 0000000003d8fed0 0000000070c237d7 VBoxRT!RTSymlinkRead+0x30a

05 0000000003d8ff00 0000000070c23894 MSVCR80!endthreadex+0x47

06 0000000003d8ff30 00000000773f652d MSVCR80!endthreadex+0x104

07 0000000003d8ff60 00000000778dc521 kernel32BaseThreadInitThunk+0xd

08 0000000003d8ff90 0000000000000000 ntdllRtlUserThreadStart+0x1d

---

Access violation (null pointer exception really) occurs in SnapshotImpl.cpp shortly after line 2421. I think NPE occurs inside the replaceMachineId.isEmpty() call at SnapshotImpl.cpp:2437, or replaceMachineId itself is null. Am guessing, as I didn't have time to create a debug build to investigate further.

[Frank Mehnert]

Still relevant with VBox 4.1.22?

[Frank Mehnert]

The reporter answered by email that he did not experience this problem with VBox 4.2.0 so closing.