VirtualBox

Opened 13 years ago

Closed 11 years ago

#9528 closed defect (fixed)

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

Reported by: Bob Kosch Owned by:
Component: virtual disk Version: VirtualBox 4.1.2
Keywords: Cc:
Guest type: other Host type: Windows

Description (last modified by Frank Mehnert)

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.

Attachments (6)

Event 1000, Application Error.txt (1.7 KB ) - added by Bob Kosch 13 years ago.
VBoxSVC.log (4.2 KB ) - added by Bob Kosch 13 years ago.
Failed to delete the snapshot - Hard disk has more than one child hard disk (2).txt (453 bytes ) - added by Bob Kosch 13 years ago.
VMM Screen Capture #1.PNG (53.2 KB ) - added by Bob Kosch 13 years ago.
VMM Screen Capture #2.PNG (54.7 KB ) - added by Bob Kosch 13 years ago.
VBox.log (95.8 KB ) - added by Bob Kosch 13 years ago.

Download all attachments as: .zip

Change History (12)

by Bob Kosch, 13 years ago

by Bob Kosch, 13 years ago

Attachment: VBoxSVC.log added

by Bob Kosch, 13 years ago

Attachment: VMM Screen Capture #1.PNG added

by Bob Kosch, 13 years ago

Attachment: VMM Screen Capture #2.PNG added

by Bob Kosch, 13 years ago

Attachment: VBox.log added

comment:1 by ddn, 13 years ago

i have exactly the same!

comment:2 by Bob Kosch, 13 years ago

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

comment:3 by blast, 12 years ago

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 process id: 0xca8

Faulting application start time: 0x01cd04974dfbbb6b

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

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

Report Id: 8c45611e-708a-11e1-9bec-002522c2d261

Version 3, edited 12 years ago by blast (previous) (next) (diff)

comment:4 by blast, 12 years ago

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.

Last edited 12 years ago by blast (previous) (diff)

comment:5 by Frank Mehnert, 11 years ago

Description: modified (diff)

Still relevant with VBox 4.1.22?

comment:6 by Frank Mehnert, 11 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use