Using Fusion 2.0.1 I created a new VM from scratch (nothing fancy, 1 processor, 96 MB, etc). Installed Windows NT 4, then installed service pack 6a, with reboots in the appropriate places. So far so good.
Next I installed VMWare tools with no apparent problems. Reboot, and shortly thereafter, BSOD. If I boot NT in VGA mode, uninstall VMWare tools, I can then boot normally (at this point, same as VGA mode). I can take an NT VM that boots/runs in Fusion 1.1,
suspend (Not powered off) it, bring it over and run it in Fusion
2.0.1just fine, so long as I don't upgrade the VM's tools.
I noticed in the Workstation forum, someone got the same BSOD using Workstation 6.5. Refer to discussion: "Vmware tools in Windows NT4 WS (VmWare Workstation 6.5) Oct 11, 2008 7:19 AM" It would appear this is a bug common to both Workstation 6.5 and Fusion 2.0.1 products.
Reproducing the bug's behavior is not hard. I reproduced it both in a pre-existing WinNT4 VM, as well as a newly constructed VM. All you need to do is install the native version of VMWare tools and reboot.
For the knowledgeable people to be able to analyze the cause of your failure, it would be helpful if you could enable mini memory dump (hope it's in NT, it's definitely in XP). In My Computer's properties, on the advanced tab, recovery options (or something like that), uncheck restart automatically, and select the mini memory dump to be produced (you will be given a choice of where to save it, I guess the default is C:\Windows\Minidump). Then manage to boot the machine again successfully, and get the minidump and post it here (while your BSOD can be reproducible, it's always better if you do post your output to be sure it's not something specific to you). Also getting screenshot of the BSOD and attaching it here was requested a few times before with BSODs (you can use the Mac OS X "Grab" utility for that).
Also post your hardware information (which revision of which Mac you have).
BSOD screen capture & hardware info attached.
I don't think NT4 has a "mini" dump option, at least I don't see it in the System Properties Startup/Recovery tab. That means the dump will be the size of the machine memory (96MB in this case). I could probably reproduce the BSOD in a VM with less memory, but it will still be multiple megabytes in size. Nevertheless the dump file is available upon request.
I get something similar with an NT4 VM which works OK under Fusion 1.1.3.
When I originally upgraded to 2.0.1 from 1.1.3 the NT4 VM froze with just a blank display before the login screen appeared. So I reverted to 1.1.3 and checked and the VM did not have the latest VMware tools installed. So I installed them, upgraded to 2.0.1 again and now get the attached BSOD before the login page appears. Rebooting in 'VGA Mode' I managed to login and install the latest VMware tools for 2.0.1 - and it still BSODs before the login page comes up.
I hope this extra information helps.
So far the only workaround I have been able to find is this:
1) Boot up an NT4 VM with Fusion 1.x, then suspend it. (wouldn't be a bad idea to take a snapshot of it at this point)
2) Copy the suspended NT4 VM to system with Fusion 2.x (*) and resume it
3) Go about your NT4 business and pray you don't have to reboot.
(* apparently Workstation 6.5 has similar NT4/vmware-tools issues)
My 84LLs are really in a vise if VMWare doesn't fix this. I have a couple of ancient programs I need to use and they do not run properly in W2k or WXP (won't bother even trying them in Vista). To make matters worse, one of those programs I cannot reinstall anyway -- custom program, had to have onsite tech support install, debug, and configure properly and that company is long since out of business. I have those programs in an NT4 VM that I've been nursing along since the VMWare 4 days.
I've been using VMWare since the 3.something days and they've been really good about maintaining backwards compatibility of older VMs. This issue, though, is a blatant "Oops, forgot to test that" on their part. A fresh new Fusion 2.x VM with a fresh NT4 installation fails immediately after rebooting with vmware-tools installed. They wouldn't have to test very many paths to find that failure.
I have exactly the same problem with VMware Server 2, created new VM, installed NT Server and SP6, all is fine until VMware Tools is installed, VM BSOD after reboot. The only fix is to remove the display driver in VGA boot mode. Anybody got a solution for this?
By any chance has anyone tried to see if this has been fixed in Fusion 2.0.2? I can't see it listed as a fixed or outstanding issue in the Release Notes.
If not I will try to get time over the next few days to test it.
I just now installed 2.0.2 and tried my NT4 guinea pig VM. 2.0.2 doesn't seem to fix the problem.
1. I booted the NT4 VM into VGA mode, and uninstalled the old vmware tools.
2. Rebooted into normal mode (as opposed to base VGA mode) ... BSOD
3. Rebooted into VGA mode and installed new vmware tools
4. Rebooted... BSOD
Seems I should have been able to boot into normal mode once I uninstalled vmware tools. May have to create a new VM from scratch to make sure there aren't any 2.0.1 vmware tools remnants or settings being retained. Won't be able to get around to that until this weekend
>BigadeP> I can't see it listed as a fixed or outstanding issue in the Release Notes.
This makes me rather pessimistic -- if not mentioned, then very unlikely to have been resolved in this release. I am beginning to doubt NT4 VM users are a high enough priority anymore, especially in this economic environment. For the treasured (gag) NT4 VM I need to use, I have resurrected my 2001 vintage PC with Win2k and VMWare 5.
I only just got around to trying this, and yes it fails for me too with 2.0.2. No BSOD now - after the NT4 blue copyright screen the display goes black instead of displaying the login prompt page.
Ho hum. Yes it looks like NT4 issues are low priority. Fortunately I only have to keep my ageing NT4 VM alive for a few more months so I'll just live with Fusion 1.1.3.
Sorry for the delay in updates (the bug has been floating around with other groups and I lost track of it). We believe this happens if you have too little RAM assigned to the guest (you can get away with less if you disable 3D acceleration, which isn't implemented on NT anyway). It's a little unclear from the bug notes exactly what "too little" means on existing versions of Fusion, but I believe 256 should definitely be enough and 128 MB may work.