jaclaz

Yep. Windows NT systems are set (I believe it is a manufacturer default since - possibly - after Windows 2000) to automatically reboot if an error is encountered. (this is profoundly and utterly wrong, a system should STOP in case fo error) The setting is in the Registry, in CurrentcControlSet, CrashControl. The 3.0 (or 3.1 or 4.0, etc-, it won't make a difference) PE is only the most simple/common way to edit that key value, the issue with doing that from another "full" OS running is only that (it may depend on the OS's involved, both the "running" system and the "target" one) is with permissions on the specific Registry hive/key (but as said there are tools/methods//workarounds), for all it matters you can use (if you are familiar with it) a Linux system via hivesx or whatever else you can use, even a hex/disk editor from DOS (but this latter would be tricky to say the least). And yes, Easy2boot allows to add PE's (I seem to remember both as .iso and as partition/disk image). But even a Windows install DVD is running a (minimal/primitive) PE, so if you can boot from such a DVD (or from it's image) that would be enough (Shift+F10, then run regedit.exe). You can also use (if you are familiar with command line) the Offline Registry Editor: http://reboot.pro/index.php?showtopic=18527 http://reboot.pro/index.php?showtopic=11312 usage is well described in one of Misty's guides: http://mistyprojects.co.uk/documents/offlinereg/offlinereg.htm Before, you, can use the Offline Registry Viewer: https://www.nirsoft.net/utils/offline_registry_view.html to make sure the key exists and it is 1 (if it is already 0, the reboot happens earlier) . Both should work just fine from your installed OS on the offline registry (your neighbour's hard disk temporarily attached). In any case, your mission (the goal), should you accept it , is to change a single byte value in the Registry of the failed system (any which way you can). jaclaz

From a PE3 you should be able to (a PE3 normally has SYSTEM privileges): 1) backup (make a copy of) the Registry backing files (just in case): SAM SECURITY SYSTEM SOFTWARE NTUSER.DAT and since Vista BCD 2) mount in Regedit the SYSTEM as (say) my_system and check hive: \SYSTEM\CurrentControlSet\Control\CrashControl (it won't be actually "CurrentControlSet", it will be either ControlSet001 or Controlset002, check which one in key \SYSTEM\Select) The value of AutoReboot should be set to 0 (to avoid automatic rebooting and thus stopping with the BSOD in case of error) If you have a PC running 7 or later you may be able to do the same, but likely you would have permission issues to change the value, you could use something *like* NIrcmd, PSexec, RunAsSystem or RunAsTI: https://www.winhelponline.com/blog/run-program-as-system-localsystem-account-windows/ https://github.com/jschicht/RunAsTI to start the regedit with higher privileges. Then reconnect the hard disk on the original PC, and try booting, two possibilities: 1) no change <- this would mean that the issue is in any of the earlier booting files/code (MBR/PBR/BOOTMGR/BCD/WINLOAD.EXE) but usually (not always) errors in these result in either a black screen or an error message (white on black) 2) you get a BSOD (white on blue) with a STOP ERROR <- post this to further troubleshoot jaclaz

If I may, there are many possible causes of this happening, Tripredacus checked one and then (IMHO mistakenly) stated "The issue is elsewhere". It is very likely that one of the updates of the (stupid) forum software is causing the issue, the "Oops! Something went wrong, Please try again" is the typical (stupid) error message (meaningless) that the board software produces, so definitely the issue/bug is on msfn.org, though I believe that pinpointing it won't be easy, over the years many similar issues surfaced, particularly with thread notification mails (that may or may not be related to confirmation ones). jaclaz

In case of need, besides the "without patch" one already linked to: https://msfn.org/board/topic/183753-windows-me-patch-for-dos-mode-is-incompatible-with-letter-assigner/?do=findComment&comment=1222058 MDGX has 4 patches listed (no idea what the differences are among them): https://www.mdgx.com/dos.htm#ME Maybe also this can be useful: https://msfn.org/board/topic/140391-windows-98-live-cd-project-update/page/4/ leading to: https://www.mdgx.com/newtip2.htm#EXIT As said, sometimes instructions/info from MDGX are not (to me) very clear, so some experimenting will probably be needed. About XMS/EMM386 (if needed) there is some new info here: https://msfn.org/board/topic/183250-how-to-disable-the-built-in-xms-driver-in-windows-mes-iosys/ jaclaz

The one you described is one way. There are others, you may want to experiment with them: https://msfn.org/board/topic/183753-windows-me-patch-for-dos-mode-is-incompatible-with-letter-assigner/?do=findComment&comment=1222058 jaclaz

The idea of posting the reference to that page was exactly to avoid any debate (which besides being endless would also be meaningless), if you need a better endless one, meet over vs. under: https://en.wikipedia.org/wiki/Toilet_paper_orientation And it is over[1]. jaclaz [1] pun intended

@NotHereToPlayGames In case of need, refer to the web page of the program: https://www.rizonesoft.com/downloads/firemin/ (bolding/underlining is mine) jaclaz

No, they are for Windows only (at the moment). But maybe by december a Mlite version may come out. jaclaz

Well, they work just fine from here. Maybe you have *something else* blocking the download of the .exe, try the zipped one: http://www.endpoint.eclipse.co.uk/wordpress/powermeterplus-exe.zip or get it from Softpedia: https://www.softpedia.com/get/PORTABLE-SOFTWARE/System/System-Enhancements/Windows-Portable-Applications-Portable-Power-Meter-Plus.shtml jaclaz

https://mattcollinge.wordpress.com/software/power-meter-plus/ But do you have ACPI enabled? https://msfn.org/board/topic/176492-laptop-says-its-always-plugged-in-solved/#comment-1136039 https://msfn.org/board/topic/100859-my-experience-installing-windows-98se/page/3/#comment-1159519 jaclaz

Only to keep everything as together as possible. https://msfn.org/board/topic/183847-last-update-broke-msfn-for-me-on-a-couple-old-browsers/ It is interesting the different approach between myself and reboot12, as I see it, the issue is with the forum software, while reboot12 seems like putting the blame on the (old) browser (that works just fine on most other sites). The funny thing is that this forum is largely populated by members that are among the few people remaining that run old OSes (and browsers). jaclaz

Personally I never liked the way BigMuscle put down the "donation/license" stuff, but technically it is more like you went to a church, got a candle, lighted it up and left a small amount of money in the offer box. There is no guarantee of sorts, and certainly there wasn't any agreement on the price, half of the board threads on Aeroglass are by people whining about the way the keys are distributed or about trying guessing how much is the minimum "free" offer they have to make to get rid of the watermark via a key. Now - for *whatever reasons* - the project is dead, so it would be interesting to understand if the donation/license effectively shelled out was (or wasn't) a fair amount for what the software offered. jaclaz

Both an old Chrome (actually Iron) and Arctic Fox do not allow to make a new thread or to reply to an existing one. The "rich text" box isn't simply there. For *some reasons* Basilisk/Serpent is working (I am writing from it). Though I know that most probably there is nothing that can be done, I thought to let people know. Any suggestion on a currently working browser (that can run in XP) is welcome (I simply cannot make head or tails of the various browser mentioned in the various threads on latest browsers for XP, I cannot even understand how they are called, the basilisk.exe I ran welcomed me to Serpent). jaclaz

Out of curiosity, don't you have right now an account (xpfan1)? What would be the need to un-ban the HaytamFrh one? I mean it has a handful on posts, none of which of particular relevance, on a single thread, . And I believe you should re-read Rules, paying particular attention to #4.b: https://msfn.org/board/guidelines/ jaclaz

May I ask you how much is what you consider a "honorable sum of money"? Since it would be not elegant to express this in dollars/euros, what about "buying power" comparison? I.e. can the total cost of using that software on three machines for a few years be compared to: 1. a coffee at Starbucks 2. a full lunch at McDonalds 3. a dinner for two at your local Pizza Hut or Domino's jaclaz

But which settings do you have for the video driver (resolution, number of colours, frequency, etc.)? Maybe you need something like Setres to change that (automatically)? https://atrandom.iansharpe.com/setres.php jaclaz

Could not find any manual from Microsoft, that's why I asked you. The quote you made, coming from this: https://superuser.com/questions/1117858/how-to-install-and-run-windows-xp-operating-system-on-an-external-hard-drive-or is about ANOTHER thing (installing XP to an USB drive, which BTW is perfectly possible), what OP did was installing XP from a USB drive, as well perfectly possible. jaclaz

Good , and you are welcome of course. Still, even if it allows you to boot without excessive typing (or with no typing at all) it remains a workaround . And the "<Windows root>\system32\ntoskrnl.exe" issue remains strange, in the sense that I can find no reason why (without any re-mapping) the grub4dos (now on the floppy) allows to boot it . There are three ways the grldr (in a setup like yours) can load an XP: 1) rootnoverify (hd0) chainloader (hd0)0+1 <-this chainloads the MBR 2) rootnoverify (hd0,0) <- or - alternatively - root (hd0,0) chainloader (hd0,0)0+1 <- this chainloads the PBR 3) root (hd0,0) chainloader /ntldr <- this chainloads the NT loader directly and it is what you are using successfully You can still try to boot to the grldr on hard disk, get to the grub> prompt and issue only: chainloader (hd0)0+1 boot and then choose the rdisk(0)disk(1) entry, if it fails, it should mean that the "fix" is the rootnoverify command, which would again point to something "wrong" in the BIOS autodetection/mapping of the hard disk. The only other possibility is something in the Registry (but what?). If you have a sure (tested) way to backup and restore the Registry (i.e. possibly a tested PE of some kind) you could try deleting the contents of the HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices and let XP re-build them on next boot, but I don't think that it can be related (I mean an error there wouldn't be solved by grub4dos booting). jaclaz

jaclaz

Care to post a link to this manual from Microsoft? jaclaz

Basically you get IMDISK , create a 1.44 MB floppy image (2880 blocks or 1474560 bytes in size), let's say the file is called NTBOOT:IMA, format it under an XP and copy to it: NTLDR NTDETECT:COM BOOT.INI (and - since you still have some space available, also grldr, just in case) *like* http://fekete.x10host.com/xxtb3000.htm#xxtb_33 The BOOT.INI in C: you modify it to have as default the c:\grldr entry and the rdisk(0) as option, with a lowish timeout, like 1 or 2 seconds. Then in C: you add a menu.lst with something *like* (to be checked manually before writing to the menu.lst): timeout 10 title Boot XP from C: find --set-root /ntboot.ima map /ntboot.ima (fd0) map --hook root (fd0) chainloader /ntldr In the BOOT.INI inside the floppy image you make default the multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional 1st disk" /noexecute=optin /fastdetect and a lowish timeout. again like 1 or 2 seconds. The idea is that when booting you go: BIOS->hard disk MBR->PBR of active partition->NTLDR->BOOT.INI->(default) grub4dos->menu.lst->NTLDR on the floppy image-> BOOT:INI on the floppy->(default) XP on C: and (normally) you don't have to press any key/make any choice when booting. While testing (and also after) you still have the possibility to drop to the grub4dos prompt, and MBR and PBR on hard disk remain untouched/unmodified. The whole stuff, when finalized should slow down booting by 2-3 seconds at most. Still, if we can find the reason why your PC behaves strangely (do check BIOS settings, like RainyShadow suggested) it would be better. jaclaz

So, we are back to square one . I am short of ideas on what could be the cause of the issue, maybe some "queer" BIOS setting? :dubbio: Let's start talking of possible workarounds: #1: install grub4dos to the MBR (so grldr will boot first, and from its menu.lst you will chainload the NTLDR+BOOT.INI) #2: change the loader name in the PBR to grldr (same as above, but has to be seen if "passing through the PBR" still works) and/or change the grldr name to NTLDR and rename NTLDR to NTLDRXP: https://msfn.org/board/topic/95537-multiboot-vista-xp-and-other-oses-with-grub4dos-menu/ #3 make a "parallel" NTLDR+BOOT.INI (with a copy of NTLDR renamed to - say - NTLDZ and hex edited to look for - still say - BOOZ.INI) #4 use (via grub4dos) a "NT boot floppy" (a "virtual" floppy, an image containing a NTLDR+BOOT.INI+DETECT.COM) There are also other ways, but they are way more complex. Of the 4 proposed ones, if I were you I would try first #3 or #4 as they are "safe" in the sense that you do not risk making a non-bootable system. jaclaz

Re-reading my previous post I made a typo, my bad , the right offset is 0x24 (36 decimal): cat --hex --skip=36 --length=4 (hd0,0)0+1 the 00000000 at offset 32 decimal is normal, check again with offset 36. Or with cat --hex --length=40 (hd0,0)0+1 (the last four bytes should be 80 00 80 00) In any case, you can boot to the XP and use a GUI hex/disk editor, such as Tiny Hexer, either the Portable version: https://www.portablefreeware.com/index.php?id=2504 or installing the "full" version: https://www.softpedia.com/get/Others/Miscellaneous/tiny-hexer.shtml to confirm the result (and if needed change those bytes[1]) jaclaz [1] they can be changed also via grub4dos, but there is the risk (as just happened) of an error/typo in the offset

Additional: Try also: 1) get to grub4dos, issue root (hd0,0) chainloader --edx=0x0080 /ntldr boot 2) choose the 1st disk entry jaclaz

Yep, this is what I am suspecting. But it shouldn't be the Registry (there the Dosdevices key uses Disk Signature+offset to partition to assign drive letters) In the MBR there is nothing about the disk number. So it can only be the bootsector. There is a field in it for disk number, but in theory it should not be used and should always be 0x80, though it seems that it is actually used when booting, see here: https://thestarman.pcministry.com/asm/mbr/NTFSBR.htm Get to grub4dos and run cat --hex --skip=32 --length=4 (hd0,0)0+1 Post output, should be 80 00 80 00 Try also this: 1) get to grub4dos and try "directly": root (hd0,0) chainloader /ntldr boot 2) choose the 1st disk entry (by chainloading the NTLDR you should be bypassing both the MBR and the PBR, but it has to be seen if NTLDR reads the disk info *somewhere else* nonetheless) Check also, once you have booted to XP with one of the workarounds tested, how is the disk seen in Disk Manager and/or diskpart, you only have one disk connected and it should be Disk 0. jaclaz