"IRQL NOT LESS OR EQUAL" when trying to re-install Win10 Pro x86

wpcoe said:

I have a Travelmate 3004 (Pentium M760, 2GB RAM, 160GB HDD) notebook which had Win10 Pro x86 (original release) that I wanted to update to v.1903....

...I then removed the hard drive, put it in a 2.5" USB adapter, connected it to my main computer and deleted the partition with Windows. (In retrospect, I could/should/might have tried other options before doing that, but...)

Oh dear, in retrospect first making a system image with Macrium Reflect Free might have been a good idea too.

You may find this post on getting a Travelmate 2423 to run the latest build instructive. It takes a lot of effort to get some of these older machine to accept the latest builds, but it can be done. @Fafhrd seems to be a master of this art.

Let's run Win10 on really really old hardware - post #365

If not, fortunately you can still get an ISO direct from Microsoft for any of the older versions of Windows 10 using this tool from Heidoc.

Microsoft Windows and Office ISO Download Tool

You'll have to scroll a long way down the list to find the original from 2015 though. Perhaps it will easily install something a bit newer, 1607, the 'Anniversary Update' perhaps?

Attachment 251273

Thanks, again, Bree. I'm halfway through a download of v.1809, so I'll just let that finish and try it anyway. BTW, I found a video with an interesting method of downloading previous (up to the previous two, apparently?) Windows 10 ISOs: YouTube

Is it possible that the x86 (sorry for using x32...) ISO is somehow different than what's on the dual x86/x64 version you have? Just wondering out loud.

Regarding that suggestion for creating a FAT thumb drive for wims over 4GB ... that's another kettle of fish. I canNOT get the CLEAN command from DISKPART to work on my Surface Pro 6 with Win10 Pro v.1903. I tried three USB thumb drives and on each one when issuing the CLEAN command, it gives the error:

Code:

DISKPART> clean
DiskPart has encountered an error: 
The request could not be performed because of an I/O device error.
See the System Event Log for more information.

The Event Log: ''The IO operation at logical block address 0x0 for Disk 1 (PDO name: \Device\000000b5) was retried.'

I copied the binary data from the Event Log for each disk error for each USB thumb drive, and the data is identical (except for the TimeCreated info, of course.)

I have a Surface Dock with additional USB ports and they have the same issue as the USB port on the Surface Pro 6 itself.

Now I wonder if the Universe is conspiring against me. LOL!

[edited to add:] The .ISO download of Win10 v.1809 x86 completed, and its size in Windows Explorer shows 3.55 GB (3,813,781,504 bytes), so that should fit within FAT32's limitations, no?

[edited again to add:] I used RMPrepUSB to create a bootable USB drive from the Win10 v.1809 x86 .ISO and there were no errors this time, but it still BSODs when I boot from it on the Acer notebook.

I checked out the old thread suggested above from a user with an old Acer, but I don't see anything there that helps me without a working Windows installation on the Acer.

wpcoe said:

I don't see anything there that helps me without a working Windows installation on the Acer.

No, you do need a Windows system from Vista or later installed to provide the boot manager to launch the Windows 10 system from.

Firstly I would use the media creation tool on your main computer to download a Windows Setup ISO.

If I were attempting what you are, I would not use a Windows Setup Installation but deploy directly from an install.wim or install.esd in the ISO image \sources folder using DISM on your main computer to an external drive* to go into your laptop. Kari has made an excellent tutorial:

Apply Windows Image using DISM Instead of Clean Install

I would not consider a UEFI/GPT deployment, it's too complicated for me. Neither would I not make a separate system partition on BIOS/MBR either. I would just use a single NTFS partition.

Make sure in Disk Manager or Diskpart that there is a single NTFS partition occupying the whole disk, and give it a drive letter, say G:\ and if you wish a volume name.

Then follow parts 2.5 to 2.9 in Kari's tutorial, then take the drive and install into the laptop. This should deploy an image to the external drive that will, on first boot, take the laptop to the OOBE part of the setup, install any generic drivers and set up the devices, and hopefully take you through the user interactive part of the OOBE, until the first full boot-up of the system.

I feel that the PC should not be connected to the internet until after the OOBE has finished. This will automatically enable you to set up a local user account - you can connect a Microsoft account at any time later within Windows when or if required.

*as you mentioned in the first post of this thread.

Thanks, Fafhrd. It took me reading a couple times to fully grasp the task, but actually it is fairly simple.

With the Acer HDD attached to my main computer via a USB-SATA adapter and formatted as one large, empty NTFS volume:

PS C:\WINDOWS\system32> dism /Apply-Image /ImageFile:G:\sources\install.esd /index:6 /ApplyDir:\

Deployment Image Servicing and Management tool
Version: 10.0.18362.1

Applying image
[==========================100.0%==========================]
The operation completed successfully.

Followed by:

PS C:\WINDOWS\system32> D:\Windows\System32\bcdboot D:\Windows
Boot files successfully created.

However, after returning the HDD to the laptop, it boots up to: Operating System not found

Tried it twice with same result.

Thinking again that maybe the old hardware expected FAT32, I formatted the HDD as FAT32 and:

PS C:\WINDOWS\system32> dism /Apply-Image /ImageFile:G:\sources\install.esd /index:6 /ApplyDir:\

Deployment Image Servicing and Management tool
Version: 10.0.18362.1

Applying image

Error: 82

The directory or file cannot be created.

The DISM log file can be found at C:\WINDOWS\Logs\DISM\dism.log

I tried that twice, too.

Any ideas why the NTFS-formatted drive causes: Operating System not found? I'm probably missing something glaringly obvious.

- - - Updated - - -

Uh, oh. That D:\Windows\System32\bcdboot D:\Windows command modified the boot control on my main computer, not on the Acer HD, i.e. the D: drive. *That* is why the Acer HD can't find an OS.

I've got to brush up on my BCDEDIT skills, because* here's what I get whenever I boot my main computer now:

Attachment 251534

Attachment 251535

The second entry (on volume 3) is the correct one.

* It was fairly easy to delete the extra/erroneous boot option via msconfig.

I understood Kari's step 2.9 was to issue the D:\Windows\System32\bcdboot D:\Windows command while I had the Acer HD (D:) attached to my main computer via USB. If not, how is it supposed to be done?

Your old hardware was from the time of XP, I believe. XP used NTFS being part of the NT family of OSs, as was Windows 2000 and NT before that. the NTFS has been around for quite a while! The Acer has run Windows 10 before on NTFS, so "The old hardware expected..." is not an explanation.

The reason why FAT32 is often chosen for USB flash drives rather than NTFS is because its simpler and the niceties of NTFS are not required, and may sometimes lead to flash drive failure through large and obscure hidden files in the journaling file system, although Flash drives can run NTFS happily for ages with some sort of internal write protection (HORM/EWF - Hibernate Once Resume Many/Enhanced Write Filter!). Windows-To-Go installations of Windows 8 and 10 in memory sticks use NTFS.

Sorry the syntax for the bcdboot command seems to be wrong for your situation in those instructions, It is possible that the third "" should have been a ">".

From an elevated cmd in Windows 10 on your main computer you just need to type

bcdboot D:\windows /s D:

Attachment 251546

The BCDBOOT.exe for Windows 10 is on the path found by an elevated cmd prompt, so the command I have given here uses BCDBOOT to transfer the system files (the /s switch in the command) and folders from D:\windows to the root of the D: drive. It should then boot.

When it boots up it will not be drive D:, just Drive C: as normal

I have no explanation of how your boot menu became mucked up.

PS. I do have a notion that command placed a new entry to your normal boot menu pointing to a non-existent windows installation on a D: drive.

BSODs relating to Windows setup are a pain in the neck since the failure just does not get back to the Windows Error Reporting (WER) system because of rollback and the error occurring within the Modified WIN PE system rather than Windows proper, and that crash dumps may not be produced.