I googled that instead and found a single Post of a guy that says that he had that issue running a Dual Monitor setup - which I have. After googling a bit I found this error is very common, but no one knows what causes it, and most seem to just accept that their systems are somehow incompatible with it - which is impossible, cause I already ran it once.īesides "invalid opcode", sometimes it also said in a green font "can't open". The error was "invalid opcode" usually followed by some hex numbers. After preparing a USB Pendrive with XBoot, I couldn't get it working, nor the latest version, nor the older ones. After fsck.ext4 in Linux, I decided to test with SeaTools for DOS, which I already used to make sure the HD was intact when I purchased it. Also, assuming than data corruption did indeed happen, I don't even know what else could have been on that bad block and get corrupted in the process, so most data on the VM should need a check - or better, starting a new installation just to be sure.Īnyways. However, due to the lack of data regarding how bad blocks may affect the inside of a VM (And/or get detected), I don't know if my theory is true or not. So it seems than that bad block was a sort of undetected black hole. Now I'm inclined to think than that was caused by the bad block, as if I deleted the corrupted file and inmediately re-downloaded it, it was also corrupt, while if I downloaded it with another name without touching the existing copy (And the space it occupied), it simply worked. At first I through than this behavior was caused due to Chrome not finishing downloads properly - anyone oldschool enough should remember than sometimes Internet Explorer used to report a file size when downloading files, yet abruptly finishing early and reporting success, leaving you with an incomplete file. I used to download files with Chrome in the VM, and if they were installable EXEs or ZIP files, they used to be corrupt with the installer reporting errors, while the Windows shell and WinRAR refused to open ZIPs.Īfter re-downloading them they usually worked, but then, I noticed that corrupted versions were 1 KB less than the expected size and the working version. This finding made me worry about some unusual behaviator that I was experiencing from months ago was related to data corruption inside the VM, which Windows XP itself may be unable to detect. I also installed the smartmontools package, and there were 22 SMART errors, of which only the data from the last 5 is available, and they reported issues with the same LBA address at pretty much the same date, with some seconds difference - I suppose that all 22 could be caused by the numerous tries to copy the IMG file. I was hoping it was File System corruption due to some improper shutdowns, but no, it had to be the HD. This prompted me to use fsck.ext4, and it detected at least one bad block affecting the IMG. I tried copypasting other big files and it succeeded, yet failed several times with that one, even after a restart. Some days ago I tried to do a copy of the IMG file cointaining my everyday WXP SP3 VM in Arch Linux, and it consistently reported a I/O error around the 1 GB mark. The HD itself was on nearly 24/7 from the install date, and passed with no issues the long test of SeaTools for DOS. The HD in question is a Seagate Desktop HDD.15 ST4000DM000, which I got early December 2013, here.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |