The question was regarding the principle of boot from USB technique ...as eventually another VM is loaded.
Another Virtual Machine is not being loaded. What's happening is a Live OS is running from VD/DVD/ISO Image or USB via Plop and that is not the same as "another VM is loaded"!
How does it enable watching the files in the broken VM
What "watching"? The purpose is to replace the target file of the BSOD just as the message states!
Anyway - I still feel it wa a VM ware issue but I have decided to drop that
No offense intended, you can think it's a VMware issue all you want but the reality is, it is not and you just don't know any better!
The bottom line is the BSOD clearly tells you what to do, "Please check this against your installation diskette.", which translates to expanding the <CD-ROM>:\I386\GDI32.DL_ to GDI32.DLL and replacing the existing C:\WINDOWS\SYSTEM32\GDI32.DLL with the newly expanded one. This is so easily and quickly done that it would take me but a few minutes to do it, either directly mounting the virtual hard disk or using as example the Kaspersky Rescue Disk. However the reality is that even in doing this it doesn't mean it's going to fix it, although one has to start somewhere and that's the logical place since the error message is explicit.
When one creates a new Virtual Machine it by default does not touch any existing Virtual Machines in any way shape or form unless you explicitly combing elements of and existing VM with the newly created one and the average no nothing user doesn't do that, not even usually by mistake. In other words under normal default circumstances each VM is self contained and has nothing to to with any other VM. You thinking create a new Linux VM affected your existing Windows XP VM is tantamount to saying when you opened Microsoft Word and created and saved a new document it deleted a paragraph out of an existing document... see how ridiculous that sounds! ![]()
