Windows XP Aborted; Can't Save State or Power Down Properly

[OzzyFrank]

Hiya. I have a problem with my Windows XP virtual machine, which it seems started after I had to reconfigure Virtualbox after upgrading Ubuntu to Jaunty 9.04. I can no longer successfully save the machine state, nor can I even power down properly it seems - which ever way I do it, it ends up as "Aborted". It doesn't crash, and I get no error messages, but invariably once it has been shut down, XP is listed as "Aborted". From what I can see when it is trying to save the state, it gets to about 80% or a bit more, disappears, and once again in the control panel it is "Aborted". When I shutdown XP by either the traditional method (ie: via the Start menu) or by telling Virtualbox to send the shutdwon signal, this ends up as "Aborted" too.

Maybe it's not a huge deal, since I can use XP fine, but it does mean it won't remember open windows from the last session, and a few settings I've changed don't immediately get recognised. I won't totally rule out that it could be an issue with the XP machine itself, I will however point out it doesn't seem to be corrupt, as I can use it fine for a bunch of tasks. The only thing I can see that is wrong is that it never comes up as "Saved" or "Powered Off". I just tested a Vista machine I rarely use, and its state was saved without issue, so it really is just the XP machine that is experiencing this.

Let me know if there are any logs or other info I can submit to help clarify what is happening here. Thanks in advance.

[Perryg]

I too have seen this with my XPpro. You should file a ticket with bugtracker about this. The link is below my post. You will need to setup a new login and password though.

[cbrownkramer]

I found this same issue occurs for me using Windows Vista (specs: VBox 2.2.2; host: Mac OSX; guest: Windows Vista Enterprise Edition).

When I ask VirtualBox VM to save the machine state, it goes through the "Saving the execution state of the virtual machine" routine and the progress bar appears to get all the way or almost all the way to the end of the process. But when I look on the VirtualBox window, it says "Aborted," and when I restart my Vista guest, it says it was improperly shut down.

Is there a fix available?

[I tried submitting this as a bug report, but it says I don't have "TICKET_CREATE' privileges.]

[Perryg]

I have found that if I click on the VBox machine tab and ACPI shut down it works as it should. Also I exported (cloned) XPpro and then Imported it again so I had a working (VMDK) copy and it seems to have fixed my XP and can once again shut down normally without a problem.

@cbrownkramer, you need to setup a new account with bugtracker and then login to the bugtracker system. They are on a different server and can not recognize your login here.

[OzzyFrank]

Hi again. I tried the ACPI Shutdown but it still ended up with "Aborted". Then I exported the XP machine and imported it again. At first, it looked promising, as while it was importing, the XP copy was listed with the others and seemed to be "Powered Off". I then had to reinstall some drivers and set up the shared folders again when I booted into it (so didn't really seem to be an exact copy), and when I saved the machine state, it was in fact "Aborted". The fun continues! (And yeah, did join the bugtracker group and post a report, but never got a reply).

[unreal]

Hi,

I am having this problem, too. MacOS X 10.5.8 host, WinXP SP3 guest. Every time I try to "save machine state" it gets most of the way through, disappears, and the machine state lists as Aborted. Starting the VM up again looks like a reboot, not a restoring of the machine state (presumably because there is no recoverable state to resume), and a bad shutdown at that-- it almost always runs chksdk on startup.

This seemed like no big deal at first ("eh, no save state, but at least booting is faster than my real PCs"), however once I started installing the applications I need I realized it can be a big problem. Some files stay open in Windows, and an improper shutdown corrupts the files. I have already had some data loss. Until this is fixed, the only safe way to take a snapshot is to shutdown the VM from inside Windows first, so backing up your data means rebooting often.

If anyone knows of anything on the user-end to fix this, it would be appreciated if you posted here. I don't really want to wait until a new version comes out, as it already sounds like just getting the bug ticket entered is taking a long time.

Also, if anyone knows a good way to keep one's data separate from the OS in the guest, that would also be appreciated. Windows installs tend to have problems over time, and it would be nice to be able to go back to a known good state without having to rewind the whole disk, especially all the precious changed application user data since then. It would also be nice [once the save state bug is fixed] to be able to always boot from the same state snapshot, instead of making a new state to keep your changed user data each time you finish a session (turning it into one long drawn out mem-leaky uptime).

Thanks!

[Perryg]

This may help the abort for you http://forums.virtualbox.org/viewtopic.php?f=8&t=22229

As for saving the data differently all you need to do is to create and attach a new VDI file as second drive.
If you make this VDI write-through then you can even revert to a different snapshot and you will not loose your data.

[unreal]

This may help the abort for you http://forums.virtualbox.org/viewtopic.php?f=8&t=22229

Yeah, they list it as problem [SOLVED] but just like the most recent post on that thread the SB16 thing doesn't do anything, at least on my setup and that other guy that posted last there. My guess is something else is going on, possibly on the Windows guest OS side with drivers. Something that for some instances is inadvertently prodded by shuffling various drivers ( I have read a handful of posts now that suggest changing some setting or another-- IO APIC, VT-x/AMD-v, SB16-- none seem to be a universal fix. Someone even said export your virtual machine and import it again... I'm not sure what is lost when one does that [snapshots?] but I'm not sure I'm ready to test that one. Why would that even work?). I posted a bug track on it http://www.virtualbox.org/ticket/5042 and added my logs to a few other bug tracks (seems similar problems have been going on in older VirtualBox versions). So far no one has assigned them to anyone, nor even touched them in a long time, so I guess they've got their hands full with Snow Leopard fixes.

It may be multiple problems intermingling, I myself have had 15 out of 17 failed save states, and the only two successes were followed by a crash during resume state. My logs suggest at least part of it may be caused by the way VirtualBox handles the DMA queue in Pluggable Device Manager during saving and/or loading state. The source is posted online, and its relatively easy to trace through to that particular logged crash, but the code online isn't searchable so I kinda hit a wall when I tried to backtrack as to what may have caused the failed assertion. For all I know the assertion was just an extra careful move and taking it out fixes the problem for 99% of cases. All I know is I don't really have time to compile my own and fiddle with it-- I did start using VirtualBox for productivity after all, not to get mired up in some Windows driver goosechase through code someone else knows way better than I. Even if I did, I'm not sure I could sort through some of the weirdness involved in saving state, that type of thing is hard to debug because a mutlitasking OS is a chaotic beast where you never see exactly the same machine state twice. My best theory right now is I happen to be saving state during some frequent low level windows driver operation that VirtualBox is not coded to properly handle interrupting, saving, or restoring. If I could figure out which driver is the problematic one (if it even is just one), I could replace it, or at least disable it during save states.

As for saving the data differently all you need to do is to create and attach a new VDI file as second drive.
If you make this VDI write-through then you can even revert to a different snapshot and you will not loose your data.

So a couple questions--

Does that mean I would be essentially doubling the data taken up on my host drive?

If I revert to another snapshot, how do I restore my data from the second drive? Seems like I would then have something akin to two out of sync mirrored drives... Would I then have to manually dump the 'Program Files' and 'Documents and Settings' back to the first virtual drive? Would Windows freak out at that? I guess that makes an ok emergency backup solution, but what about being able to snapshot a booted state (if I ever get 'Save machine state' working) ?

Thanks!

[Perryg]

The actual purpose of the second drive is to store your data in. If you revert on the main drive you loose the programs that you installed, but not the data that is stored in the second drive if you mark it as write-through or immutable, because it is not included in the revert. If you plan for this you can make the first drive size and the second drive size to reflect this and the actual combined size could be the same as the one do-all drive.

[unreal]

The actual purpose of the second drive is to store your data in. If you revert on the main drive you loose the programs that you installed, but not the data that is stored in the second drive if you mark it as write-through or immutable, because it is not included in the revert. If you plan for this you can make the first drive size and the second drive size to reflect this and the actual combined size could be the same as the one do-all drive.

I've been reading up on virtual drives. It sounds like what you mean is there would be another separated drive (D: on Windows) that would be write-through, and thus safe from snapshot reverts. That scheme makes a lot of sense for any other guest OS, but for Windows it's more complicated... First off, while some Windows applications are well behaved, the ones I specifically need Windows for are not and install config and data files somewhere other than MyDocuments. So I basically would need Program Files and Documents and Settings folders to be on the write-through drive. On other OSes, you can just create a hard link for any given folder to another drive, but on Windows that feature doesn't exist, and if you just copy the folders to another drive Windows and any badly written applications will freak out because the locations are hard-coded in various places to look on the C: drive.

I think what I may end up doing is combining the above with some sort of script or thrid-party back-up tool to just copy those folders to the write-through drive before a snapshot restore and then back afterward.

Hey, I have a question-- I read you can make an existing normal virtual disk immutable after the fact; can you then later change an immutable disk back to normal? (Seems necessary for every time a new hotfix comes out )


Looks like no news on the "Save machine state crash" front. Anyone else still having this problem or found a solution?

[unreal]

So someone finally responded to the tickets I posted logs to. Looks like the assertion problem has been fixed and will the fix will be part of version VirtualBox 3.0.8. However, based on the variety in the logs, I am not totally convinced this is the only problem with saving and resuming state (or even just shutting down, as some users have reported). So, if anyone has been having these problems, try 3.0.8 when it comes out, or checkout the current source and see if you're still having issues, and if you are they want to see your logs added to the existing tickets #4020 or #5042.

Cheers!

[OzzyFrank]

Well, I just removed 2.2 and installed the latest 3.0.6. and after saving the machine state I thought it was fixed, as it said "Saved"... for a few nanoseconds, then went back to the familiar "Aborted". Forgive me for saying this is really a sorry state of affairs. I'm even considering going back to VMware, and that's really saying something, hehe!

[unreal]

Well, I just removed 2.2 and installed the latest 3.0.6. and after saving the machine state I thought it was fixed, as it said "Saved"... for a few nanoseconds, then went back to the familiar "Aborted". Forgive me for saying this is really a sorry state of affairs. I'm even considering going back to VMware, and that's really saying something, hehe!

Yes, same here-- the problem exists in 3.0.6 and prior versions, but like I posted, frank said it was only just recently fixed and won't be in the already released version. It is fixed and the fix will be present in the new version (3.0.8), when that comes out. If you would like to find out right now if the fix works on your set up, try downloading the current source and compiling it. It is experimental, but it may be better than waiting for 3.0.8. In my experience, new releases come out pretty frequently with VirtualBox.

I wouldn't go back to VMWare, I loved the interface better than all the others, but performance-wise it has scored consistently slower than both Parallels and VirtualBox-- which are on par with each other. So if you have to go with a paid option, I'd go with Parallels. In terms of compatibility, this is the only real problem I have had with VirtualBox so far, so to me at least it seems worth not having to shell out the $70 or whatever bucks for Parallels. But that's just my opinion.

[unreal]

Hello again! VirtualBox 3.0.8 is now out. I tested the bug against this version and it seems to be fixed for my set up. I can now save and restore sessions and even just power down without getting the dreaded Aborted.

However, there is one caveat to the fix-- I noticed if I left a USB device plugged in, the same symptoms would resurface. I opened another ticket for this, check out #5146 (http://www.virtualbox.org/ticket/5146). Please post your logs if you are having the same problem. If you are still having this problem without USB devices attached (and you have tested this on the new VirtualBox 3.0.8 ), then please re-open ticket #5042 and post your logs there. Thanks to everyone that contributes!