System: Dell PowerEdge sc1420 with dual xeon and Adaptec 2420SA SATA RAID (supported by OS); 10 GB memory (2x4, rank 2, organization x4, in DIMM1 & DIMM2; 2x1, registered, organization x8, in DIMM3 & DIMM4) This computer is currently running Windows Server 2008 R2 Enterprise which was installed with no problems. Objective: clean install of Windows Server 2012 R2 Standard on an otherwise unused RAID array disk set. All attempts to boot from DVD result in loading of files (grey progress bar on bottom of screen), brief dark screen, then black screen with a blue windows logo for about 2 seconds and then a flash of about 10 lines of error notifications on a black screen for about 1/4 second (unreadable), and then a reboot of the computer. Coreinfo.exe confirms that cpus DO support NX and PAE; do NOT support VMX (virtual machine enhancements). Attempts to run memtest.exe from boot disk tool-menu startup result in an error message that the memtest.exe file is corrupt. Running memtest.exe from Windows 2008 R2 install disk results in all memory tests passed!

Attempted booting with multiple DVD's (some +R, some -R, all verified) burned from.iso. These DVD's were used successfully to install Windows Server 2012 R2 on an HP Pavilion.

Also changed DVD drives just to rule out DVD hardware. Running CHKDSK from Windows 2012 R2 on HP Pavilion shows no problems; running CHKDSK from Windows 2008 R2 on the Dell system on the same disks shows some problems. Running checkdisk on the Windows 2008 R2 install disk from the Windows 2008 R2 installed system shows no problems. All disks burned and verified on same system. Also attempted to boot from USB thumbdrive with copy of DVD on it. Same results: system loads files then reboots at first Windows logo.

So that would rule out disk quality issues per se?? Started to try an upgrade rather clean install to see if any errors were announced. None were announced as the system went through much of the process. I aborted somewhere along the way before committing to the upgrade because 1) the most likely outcome was it would not boot after install (I don't really need the practice in restoring); and 2) even if it did reboot, having a system that can't be repaired by booting the install disk is pointless. All disks and raid arrays are recognized and usable by RAID controller card and by Windows Server 2008 R2.

Disks are within spec for use with Adaptec 2420SA (1TB @ 300). Is VMX (aka VT-x) actaully required for ANY install even though Hyper-V is not intended to be used? If so, it is too bad that the Microsoft system requirements ( ) don't make that clear. And lack of VMX support really doesn't explain the memtest.exe 'corruption' issue. Or is it maybe something unique about the files on 2012 R2 disk (or disk image on USB) that are causing some problem with the chipset processing?

Description: Adaptec Storage Manager v5.01.16862 for use under 32-bit Windows Vista, Server 2003, Windows 2000, and XP. Release Notes are available here. Caution: If a previous version of Storage. Adaptec Serial ATA II RAID 2420SA Adaptec Serial ATA II RAID 2820SA. Compatible Environment.

My vote would be for the latter of the issues, but I have no clue why or if it is remediable. So here is what I think is the final understanding of this problem: First, one additional piece of important information: The computer successfully moves into and through the Windows Boot Loader phase and succeeding phase ONLY for Windows 8.1 32-bit, but NOT for Windows 8.1 64-bit nor for Windows Server 2012 R2 (only 64-bit). The Windows Boot Manager phase (which precedes the Windows Boot Loader phase) is either 32-bit or 64-bit (64 –bit for this case) and is loaded by the 16-bit stub program (Bootmgr) which starts in real mode. Keygen Superior Drummer 2.0 Mac Torrent on this page. Windows Boot Loader of course runs in either 32-bit or 64-bit (64 –bit for this case) according to the product being installed. By inference, the essential problem is occurring in conjunction with the loading of a WIM file to start the Windows Boot Manager.

The boot manager starts ok and generally shows its essential screens (Windows Boot Manager; Advanced Boot Options) or proceeds to load files for transition into Windows startup in the succeeding Windows Boot Loader phase (that doesn’t “boot” but rather loads the system). Download Free Fluid Flow And Heat Transfer In Wellbores Pdf Free here. This is best confirmed by the announced corruption of the memtest.exe file when selecting Windows Memory Diagnostic from the Windows Boot Manager Screen. If allowed to continue loading files to pass control to the Windows Boot Manager, the type of abort and resulting immediate restart that occurs is that which you would associate with unhandled cpu exceptions (invalid instruction, memory out of range, wild interrupt, etc.) that most of us have not commonly seen for 20 years (since beginning to use well behave OS’s from Windows NT 3.1 and on). So, the problem obviously is due to a failure to properly mount the WIM file and/or properly access it (probably the latter) when running in 64-bit protected mode. This is independent of the hardware on which the install disk is actually mounted (DVD or USB-flash), so it is NOT a hardware problem per se.

Since the WIM is mounted early in the process, Boot Manager may well have loaded it using BIOS routines to access the physical device on which it resides rather than loading 32-bit or 64-bit drivers of its own. Hence, if the BIOS does not “mount” the WIM in a way that is later fully compatible with access from the 64-bit systems being loaded, it could cause apparent file corruption. If it is only partially incompatible some functionality may appear quite usable (like loading files) until later detected. This is vague on my part, because the exact nature of the incompatibility cannot be readily determined from the information available. But the consequence is the same: the system cannot boot from the install disk, either for initial installation or repairs. Incidental conclusion: The 64-bit boot manager code for Windows Server 2008 does not exhibit this faulty behavior, but the 64-bit code for Windows Server 2012 does.

So the problem is not inherent with loading 64-bit server OS’s. Expectations: If the system were to be upgraded using the features of the install disk while running an installed OS, say Windows Server 2008 R2, it might well succeed and yield a fully functional system upgraded to Windows Server 2012 R2 (because the installed operating system is started from discrete files, not from a WIM file). However, in order to perform a disaster recovery using Windows resources (such as image backups from Windows Server Backup), one would have to presumably boot from a Windows Server 2012 64-bit install disk or Windows Server USB recovery drive. Of course we know that the Windows Server install disk will not boot and we can be fairly sure that the problem will migrate to any Windows Server USB recovery drive that is created. My inspection of a Windows 7 System Repair CD shows that is based exclusively on boot.wim, not discrete files! Of course a generated image for a WIM for Windows 2012 USB recovery drive might not have the flaw that drives this behavior, but it probably would. Problem conclusion: A BIOS upgrade would be required for compatibility with Windows Server 2014 clean installation and any maintenance; and none is available from the OEM.

Problem not resolved, but understood for future reference. Thanks to Tim whose comments helped me focus my thinking. Do you have the BIOS required by Dell for supporting 2012 R2? I haven't had this happen on a Dell box, but I have had it happen on other boxes. Box worked fine with 2008 R2, but when trying to install 2012 had experience similar to yours.

Installed the appropriate BIOS, and 2012 installed without issue. I do not find the SC1420 on for 2012 R2. Maybe I'm not looking for the right thing. But if Dell supports it with 2012 R2 it should be listed there. That's where vendors get their systems listed when they have certified them to run each version of the operating system shown..: .: . Thanks for the reply and info. It is better to know that this has happened at least occasionally for others.

This is a 'wildcat' attempt to upgrade a server not on the catalog of tested/certified hardware. Actually Dell has backtracked on support for this 'legacy' server. They do not support it for OS's beyond Windows Server 2003. They DID once post a whole lot of signed 64 bit drivers for virtually everything on the box SPECIFICALLY to facilitate upgrades to Server 2008, although they never formally supported the upgrade. They have since removed most of those drivers, and it is clear that they changed policy to not post drivers for unsupported configurations as they had richly done in the past. I am using the latest available BIOS, 4/17/2006, which was pre-Server 2008. This BIOS most likely supports the latest and last production Xeon models compatible with this motherboard chipset and socket, and that's all.

The Xeon cpus are Irwindale and I knew they didn't support VT-x. I was actually surprised to see that coreinfo.exe reported NX present; from my experience with coreinfo, if it tells you it is on then it is indeed turned on in the BIOS and WORKING (but this BIOS has no settings with regard to managing NX). BTW, I have since found that this system moves right along without failing when attempting a Windows 8.1 Enterprise installation.

It is supposed to be the same code base, and you would think also the same installer. But Windows 8.1 may very well support a wider variety of legacy devices than Server 2012 R2. This does suggest a possibility of device driver issues.

There are a few possibilities: 1. As you mention, a mystery BIOS incompatibility (which will not be resolved). This could be an issue of how the BIOS deals with some off-nominal quirk of DVD format standards necessary to read this particular disk, but I have not heard any specifics. A use of VT to mount some part of the kernel loading phase or session manager startup ONLY in Server for the installer. It obviously has passed the Windows boot loader phase when this abort occurs. (this would be irresolvable, but is not very likely and is certainly not publicized--in fact it is publicized at least in forums that you DON'T need VT to install). Some driver incompatibility during the kernel loading phase or session manager startup.

This seems to occur almost immediately after the video driver is loaded and put to work. You see the blue logo and whirling circle for a very brief moment. The current video card is a PCI Rage XL shipped with the system from Dell; it has issues even with Windows Server 2008 R2 in that the standard windows video driver cannot successfully command it to go to 1280 x 1024 (32 bit) of which it is perfectly capable (black screen reverts to previous settings). I will try a much newer (still legacy) PCI GeForce 6200 video card with WHQL drivers for Windows 7 64-bit on Monday. If that is the problem it might work 'out of the box' with the server install disk. I DID already try booting with low-res video from the Advanced Boot Option menu, with no joy. So I am grasping at straws, but thanks again for the insights.

Your advice and reports of others’ experiences actually drives me to think I am dealing with possibility 1 above rather than 3. So here is what I think is the final understanding of this problem: First, one additional piece of important information: The computer successfully moves into and through the Windows Boot Loader phase and succeeding phase ONLY for Windows 8.1 32-bit, but NOT for Windows 8.1 64-bit nor for Windows Server 2012 R2 (only 64-bit). The Windows Boot Manager phase (which precedes the Windows Boot Loader phase) is either 32-bit or 64-bit (64 –bit for this case) and is loaded by the 16-bit stub program (Bootmgr) which starts in real mode. Windows Boot Loader of course runs in either 32-bit or 64-bit (64 –bit for this case) according to the product being installed.

By inference, the essential problem is occurring in conjunction with the loading of a WIM file to start the Windows Boot Manager. The boot manager starts ok and generally shows its essential screens (Windows Boot Manager; Advanced Boot Options) or proceeds to load files for transition into Windows startup in the succeeding Windows Boot Loader phase (that doesn’t “boot” but rather loads the system). This is best confirmed by the announced corruption of the memtest.exe file when selecting Windows Memory Diagnostic from the Windows Boot Manager Screen. If allowed to continue loading files to pass control to the Windows Boot Manager, the type of abort and resulting immediate restart that occurs is that which you would associate with unhandled cpu exceptions (invalid instruction, memory out of range, wild interrupt, etc.) that most of us have not commonly seen for 20 years (since beginning to use well behave OS’s from Windows NT 3.1 and on).

So, the problem obviously is due to a failure to properly mount the WIM file and/or properly access it (probably the latter) when running in 64-bit protected mode. This is independent of the hardware on which the install disk is actually mounted (DVD or USB-flash), so it is NOT a hardware problem per se.

Since the WIM is mounted early in the process, Boot Manager may well have loaded it using BIOS routines to access the physical device on which it resides rather than loading 32-bit or 64-bit drivers of its own. Hence, if the BIOS does not “mount” the WIM in a way that is later fully compatible with access from the 64-bit systems being loaded, it could cause apparent file corruption. If it is only partially incompatible some functionality may appear quite usable (like loading files) until later detected. This is vague on my part, because the exact nature of the incompatibility cannot be readily determined from the information available. But the consequence is the same: the system cannot boot from the install disk, either for initial installation or repairs.

Incidental conclusion: The 64-bit boot manager code for Windows Server 2008 does not exhibit this faulty behavior, but the 64-bit code for Windows Server 2012 does. So the problem is not inherent with loading 64-bit server OS’s. Expectations: If the system were to be upgraded using the features of the install disk while running an installed OS, say Windows Server 2008 R2, it might well succeed and yield a fully functional system upgraded to Windows Server 2012 R2 (because the installed operating system is started from discrete files, not from a WIM file). However, in order to perform a disaster recovery using Windows resources (such as image backups from Windows Server Backup), one would have to presumably boot from a Windows Server 2012 64-bit install disk or Windows Server USB recovery drive. Of course we know that the Windows Server install disk will not boot and we can be fairly sure that the problem will migrate to any Windows Server USB recovery drive that is created. My inspection of a Windows 7 System Repair CD shows that is based exclusively on boot.wim, not discrete files! Of course a generated image for a WIM for Windows 2012 USB recovery drive might not have the flaw that drives this behavior, but it probably would.

Problem conclusion: A BIOS upgrade would be required for compatibility with Windows Server 2014 clean installation and any maintenance; and none is available from the OEM. Problem not resolved, but understood for future reference. Thanks to Tim whose comments helped me focus my thinking.