jaclaz

With all due respect, you seem like mixing all together a lot of things of which you have only a minimal understanding. It is very unlikely (please read as "it won't work) that you will ever be able to start a later OS with the boot files of a previous one. As well your attempt (if I get right what you attempted doing) to repair a Windows 7 boot using Vista files/tools is completely futile. It is the first time I read about partitions disappearing when deleting the boot files, it makes very little sense, the NT 5 boot files (NTLDR, NTDETECT.COM and BOOT.INI) are completely offline/non accessed once the OS is booted. the NT6 file BOOTMGR is as well completely offline/not accessed BUT the \boot\BCD (which is actually a Registry hive) is instead online when the os is booted as it is mounted as HKLM\BCD00000000, so only deleting this latter file may (though I doubt it) create issues (like preventing the deletion or crashing) but I cannot see how it can modify anything connected to partitioning/filesytems. Partitions DO NOT disappear, what may happen is that data is corrupted/changed in the MBR partition table, the Magic Bytes become invalid or - much more rare and the symptom is having RAW partitions - that some data in the PBR is corrupted/changed. It is possible, since you are using (why) XP on a disk with partitions aligned to megabyte (2048 sectors) that it corrupts something, but it is unlikely, the only reports we have is about the XP disk manager that corrupts logical volumes inside extended, never primary partitions. About this there are only two "conventions" about disk partitioning: 1) up to XP partitions start and end aligned to heads and cylinders (and since the most common HS geometry is 255/63 this means that first partition starts on 0/1/0 - i.e. 63 - and end on n/254/63) 2) starting from Vista partitions are aligned to whole megabytes (actually mebibytes) i.e. 2048 sectors x 512 bytes each = 1048576 bytes, the first partition starts at 0/32/33 - i.e. 2048) Clusters are related only to filesystems and their size have nothing to do with disk partitioning. The NTFS default cluster size is 4096 bytes (no matter which OS, on any practical size of a volume), FAT32 cluster size affects (or is affected by) volume size, the FAT32 default cluster size of 4096 bytes cluster size applies only up to around 8GB, larger volumes will have larger cluster size. If you want to troubleshoot the issue, you will need to learn how to make backups/copies of the MBR and of the PBR's and compare them in order to pinpoint what actually changes. When you use "automagical" tools (easus/eassos/etc,) you don't know what they do, for all we know they might fix the actual issue but create another one. About bootrec, you have to understand what it does: https://ss64.com/nt/bootrec.html Bootrec /fixboot writes new bootsector CODE, leaving the DATA in it untouched Bootrec /fixMBR writes new MBR CODE, leaving the DATA in it untouched so if the issue is with either the MBR or PBR DATA, they won't do anything. The above link explains also how to use the bootrec /rebuildBCD (i.e. making a backup and then deleting the existing BCD in order to force the tool to completely rebuild a new BCD), still, given the mixing of files and operating systems, it is entirely possible that the installed OS is not detected or not detected properly, so often it is needed (though they both need some experience) to use BCDboot and/or BCDedit manually, in any case you must use the tools coming from the exact same OS you are trying to boot/repair. A possible alternative (easier to use because it is GUI, but that still needs some knowledge of the way the BCD works) could be BOOTICE: http://reboot.pro/files/file/592-bootice-v1332/ jaclaz

Boot.ini is ONLY a settings file, it tells NTLDR what to boot [1]. You are loading the NTLDR of your Shorthorn that (evidently) can boot the (previous) operating systems (2000 and XP), the inverse does not work, i..e. the 2K NTLDR can boot both NT4 and 2K but not XP, the XP NTLDR can boot XP and 2K (and possibly also NT4 but it would need to be tested) and so on. Vista and later can ONLY boot via BOOTMGR. You can add to your 2K or XP BOOT:INI an entry loading GRLDR (the grub4dos bootmanager) and have in its configuration file (menu.lst) a choice to chainload the BOOTMGR. Other point: the "press any key to boot from CD" message comes from a file on the CD called bootfix.bin. The idea is that you may (or may not) being booting a CD to install the windows for the very first time, i.e. on a blank/unpartitioned hard disk (intended use) OR you might be booting it on a machine with an already partitioned disk OR (common enough) you forgot the CD in and left boot priority unchanged and you booted to the CD by mistake on reboot after install, so, once the CD has been booted, the bootloader/bootsector of the CD runs bootfix.bin that checks the MBR being valid and only if it is, it shows the message. If the MBR is blank or invalid, the CD continues booting without need for a keypress. Some more details here: http://reboot.pro/index.php?showtopic=9540 jaclaz [1] to be fair, though unrelated, non-arcpath entries in BOOT.INI are also parsed by BOOTMGR, I believe up to the one in Windows 8 or 8.1, surely up to 7.

It is a Schroedinger antivirus. jaclaz

Well, you asked for it (I believe it is the only one): https://www.tgsoft.it/prodotti/viritexplorer.asp jaclaz

Hey AstroSkipper, I didn't start it . I understand that sarcasm may be difficult to detect, but it seemed to me clear enough jaclaz

Sure, not only Germany, the US also banned Kaspersky: https://msfn.org/board/topic/184271-us-blacklists-kaspersky-antivirus-as-an-unacceptable-risk-to-national-security/ but that has nothing to do with my post, which was about the additional vetting of German workers in a German firm, checking their Germanic origin is only part of the answer. jaclaz

It wasn't a Cold War joke, it was a warning to those that need or want to be really-really sure that they can trust the makers of the antivirus. I guess that those people will need besides the basics (genealogy trees, blood exams and DNA analysis) also a written declaration about political views (and maybe also religious beliefs) of all workers involved. jaclaz

Hmmm, I don't know how/where else to look for the origin of that volume. What are the contents of the key with that GUID in MountedDevices? As said earlier, if it is not a hard disk volume it should contain some info on its storage path, usually leading to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\STORAGE Some are "generic" RemovableMedia" or "Volume", others may lead to "USB", "USBSTOR", or to the name of a driver. I would try using DriveCleanup (by Uwe Sieber): https://www.uwe-sieber.de/drivetools_e.html and see if the volume is listed among the ones that can be removed (using the -T parameter) and if it does, I would try clearing the devices (unless you have other devices that you want to keep, even if disconnected). Maybe, even if removed this way it is recreated at reboot, which should mean that you have some driver or service running that recreates it. Also running the (similar) DeviceCleanup tool may give some results, but cannot say, that one is more about Code 45 devices: https://www.uwe-sieber.de/misc_tools.html#devicecleanup jaclaz

Not only, some of those workers, even those with no less than 15 generations certified Germanic origin may be communists (openly or secretly). jaclaz

Surely 7 is "heavier" than Vista, but on a normal NTFS filesystem the number of files present in WinSXS is irrelevant (and BTW most of them are hardlinks) I believe more simply that 7 loads a lot more files when booting. Reducing the files in WinSXS has always been about "crazy" projects like installiing 7 on FAT32 or when really squeezing the install size for mini-windows and PE's. On PE's on slow media (USB) there are optimization techniques, but even if they can be replicated on a "full" 7 on internal HDD or SDD, they won't give any practical advantage And NO, that cmd is intended for offline (and basic/reduced) OS, if you try running on a booted OS you will likely botch it for good (if it works at all). jaclaz

Yes, Windows Vista uses BOOTMGR+\boot\BCD, 7 and later also. Windows Vista can work on FAT32, it just won't install on it. If you install on NTFS, then copy the whole contents to a FAT32 volume, it will work (Dietmar did it years ago), later GD 2W10 posted a simpler method including a couple needed tricks to avoid the errors: https://msfn.org/board/topic/102556-how-to-install-windows-vista-on-a-fat32-partition/ With 7 that is not anymore possible, because 7 has too many files for FAT32 in its WinSXS directory, though it is possible to have it working by removing files from the WinSXS folder (there are some "mini-windows 7" that can be deployed to FAT32): http://reboot.pro/index.php?showtopic=19643 There is somewhere (I believe on reboot.pro) but I cannot find it right now a topic about the files that can be "safely" removed from a full windows 7. install to allow copying it to FAT32. If I manage to find it, I will add a link to it. Anyway, likely the WinSxS_Reduce_Trusted.cmd will work for it: http://reboot.pro/index.php?showtopic=21977&page=13&#entry216384 jaclaz

You can mean whatever you want by i386, but using the same language and conventions as other people usually helps in understanding. Up to XP NTLDR is used Starting from Vista BOOTMGR is used. Your experiment with Shorthorn/Longhorn shows that in some versions both NTLDR and BOOTMGR are used, still the XP recovery console fixboot can only rewrite the PBR code to invoke NTLDR. Since that works it means that - at least once installed - your Shorthorn/Longhorn boots via NTLDR (and not via BOOTMGR, unless there is another bootsector invoking BOOTMGR in BOOT.INI). Checking the contents of BOOT.INI should be enough to verify (or confute) this. A good idea would also be to make a copy of the bootsector (on FAT it is first sector, on NTFS it is the file $Boot or first 16 sectors of volume) before running the XP recovery console (when the OS is failing to boot) and compare it with a copy after having fixed it, there may be other changes besides the OS loader name. I don't know which idea you are referring to, I don't recall having talked of Disk Manager in this thread. However there is a known issue with the XP disk manager when used on a disk that has been partitioned with Vista and later. As soon as you access it with Disk Manager AND change something (like making a primary partition active) then all logical volumes inside extended disappear. The issue is talked about here: http://reboot.pro/index.php?showtopic=9897 Only accessing the disk with Disk Manager shouldn't create issues, and in any case the issues are only related to logical volumes inside extended (primaries are unaffected), so what you report seems like news, and it is likely something peculiar of Shorthorn/Longhorn. jaclaz

I had the same issue, but with an older OS, another gpu, and with a CRT monitor, in my case also an older driver changed nothing. jaclaz P.S. Ooops, a link (tagged "I'm ill, doctor. Help!") fell out of my bag-o-links: http://jdebp.info/FGA/problem-report-standard-litany.html

No windows version use I386 to boot, I386 is a folder where installation files are for some windows versions. I believe you mean that Longhorn requires NTFS filesystem for the "system" (what MS would call boot) partition. Since NT 3.1 Windows has been designed to work with two partitions, one (that everyone calls boot, but MS calls system) that contains the boot files and is active in the MBR table and one (that everyone calls System, but MS calls boot) containing Operating system files: http://www.multibooters.co.uk/system.html The requirement for this second partition being NTFS came with Vista (but very likely Longhorn already has it), the first one can be anything, including a FAT12 bootdisk. It really depends on how you install whether you have a single partition (that then needs to be NTFS) or two (in which case only the second needs to be NTFS). You will likely have different drive lettering if you are using one or two partitions, depending on the specific way you install: http://www.multibooters.co.uk/quirks.html#c_drive Bootsect.exe will work on FAT12/16/32 and NTFS, the third party utilities I mentioned probably only on FAT12/16/32 (but has to be checked). Up to XP Windows boots via NTLDR (and NTDETECT.COM) Vista boots via BOOTMGR AND NOT via NTLDR. Longhorn depends - I believe - on specific version. jaclaz

To be added (politely and in a calmly way): Do not mistake a technical board for social media. A place called Funny Farm is likely supposed to contain something funny, an endless amount of random links to (BTW crappy) random sites is not funny, and is (somehow) appropriate on twitter or facebook or instagram You have by now what? three or four long threads filled with this stuff. Do you really-really need to start new threads for these? jaclaz

In MBR style disks the booting sequence is either: BIOS->MBR->PBR of active (primary) partitiion-> NTLDR (and NTDETECT.COM)->BOOT.INI->choice of OS or BIOS->MBR->PBR of active (primary) partitiion-> BOOTMGR ->\BOOT\BCD->choice of OS The "fixboot" command in XP recovery console simply re-writes the PBR (bootsector) code with the one designed to invoke NTLDR. The equivalent in a "full" system (Vista or later) is bootsect (with the /NT52 switch), NO idea if there is one in Longhorn nor which type of code it writes, some details on various versions: https://msfn.org/board/topic/171749-bootsectexe-various-versions-compared/ Since longhorn/shorthorn is midway between XP and Vista it is possible that the version you installed (that clearly needs to use NTLDR as it is fixed by the XP recovery console) *somehow* writes the bootsector invoking BOOTMGR and then Vista does not recognize the install (basically because there is no BOOTMGR not \boot\BCD. Third party, both bootpart.exe (by Gilles Vollant) and MBRFIX.exe (by Kaare Smith) should do (create a bootsector invoking NTLDR[1]), see also: http://reboot.pro/index.php?showtopic=5251 Something that you can try (as it costs nothing) is to make a copy of NTLDR and save it as BOOTMGR along NTLDR, very likely the bootsector loading code is the same for both. As a matter of fact at least in some versions of the boot code - on NTFS - it is possible to change the pointer to the string with the name of the loader as both strings NTLDR and BOOOTMGR are present (on FAT/FAT32 you need to change the actual name). Of course IF my guess is correct, the "XP" code invokes NTLDR and has the message "NTLDR is missing" the "Vista" one invokes BOOTMGR and has the message "BOOTMGR is missing", your longhorn code could be invoking BOOTMGR but still have the "NTLDR is missing message", but it may well be any other type of problem. jaclaz [1] though it has to be checked if it is possible to do that on a NTFS volume, very likely both tools can only deal with FAT (16 or 32) volumes, so they would only work if you use a (small) Boot partition (what Microsoft would call System) and bootsect.exe remains the only simple tool to fix the issue

Hmmm. How do you know that OP (from Korea) speaks Japanese? jaclaz

Yep, it is strange. By decoding the GUID/uuid, you should be able to confirm that this new GUID has been newly generated. But if it was, it should be foundable at least in MountedDevices in the Registry, AFAIK the GUID is generated when the mount manager detects a device and then it is written in the MountedDevices, the theory - till now - was that the GUID was generated like that and then, even if the device was not anymore present, the value remained there (and possibly in a few other places in the Registry), but if a new GUID has been generated *something* must have triggered it (and it should appear in mountvol, unless it is again disconnected). If it is, you can by the value determine either the disk signature or its Storage Path. At least on XP (but 7 might behave the same) some keys/values may not be findable in Regedit, though it is admittedly a rare case you could try a third-party registry tool Could it be connected to some Virtual Disk Driver? (besides "proper" virtual disk drivers that you may have intentionally installed, some CD/DVD burning tools sometimes install one). jaclaz

They are likely PWM fans. You can make a circuit to fake the signal (example here): https://hardforum.com/threads/generate-fan-rpm-signal-w-o-fan.1606397/ https://www.techidiots.net/notes/fake-fan-sensor But there are pre-made commercial solutions, google for "fan spoofer" or "fan simulator" (used for oil-immersed cooling, often miners). Of course YMMV. jaclaz

Yep, I think there is no hurry, it doesn't seem to me as a "serious" issue, whatever it is the cause, it should affect only the defrag tool, that you surely don't use very often. The charger catching fire seems like a much bigger problem, did it actually get flames/sparks (rare, dangerous) or did it only let out the magic smoke (common, usually harmless)? https://en.wikipedia.org/wiki/Magic_smoke jaclaz

The issue is with Sunday afternoons. https://www.hhgproject.org/entries/wowbagger.html jaclaz

Maybe useful, maybe not: http://www.tsac.co.uk/javavm/index.php jaclaz

Everything is possible, but what you report is strange, in the sense that (AFAICR) Windows 2000 (like NT 4.00) was essentially a "same" OS with only a few differences in the Registry and/or in a few other files, the installation, drivers and booting should be exactly the same. Errors *like* line 53 of INF file" is wrong may be due to *something* in nlite targeting the specific Professional edition (which is of course the "popular" one) and creating a problem in the .inf on the "other" edition, or maybe those SATA drivers are somehow not compatible with Datacenter edition. Still, if your BIOS has IDE compatibility mode, no drivers (integrated or not) should be needed. You could try not integrating the drivers with nlite but use the "normal" F6 floppy way to install them (it is possible to use a grub4dos mapped virtual floppy to replace the "real" floppy which likely you don't have) but it is of course very little documented and experimental, really tested only on XP installs. (by the time grub4dos came out and floppy drives became extincted the only NT os people were interested in was already XP). jaclaz

The GUID's are uuid's Version 1, even if they appear "random" numbers they encode the date/time when they were generated and the MAC address of the machine on which they were generated. The linked uuid tool can decode them. Since they are generated the first time a volume is detected by the OS, when (as it is in your case) they are all within a few seconds it means that there were no "later additions" of devices or resets/modifications/etc. Decoding the GUID of your ghost volume could give you the date when it was connected first time. The Mounted devices hive contains two kind of key names: 1) beginning with \DosDevices\ followed by a drive letter and colon 2) beginning with \\?\Volume followed by a GUID The content of each key are (in the case of fixed media) the disk signature+the offset to the partition/volume, in case of removable media the "STORAGE path" to the device. In practice the hive contains a (partial) "history" of volumes connected to the machine, as the contents remain "sticky" in the hive until they are overwritten/updated by some other volume mounted. It is possible to either delete all entries but the ones related to the volumes you actually have or delete completely the contents and let the system rebuild them, but in your case, if there are entries related to the "ghost" volume, I would try deleting just those, as it is possible that for *whatever* reasons the defrag tool reads the "ghost" volume from that hive. The other place where some volume info is stored is the (in theory related to Explorer) Mountpoints2 in HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2, though it is less likely to be the source for that "ghost" drive. I would make a search through all the Registry for the GUID of that ghost drive (without the curly brackets) as the data may be in some other places, depending on how it was originally connected. jaclaz

Yep, those are volume GUID's. It is very common to fail to communicate properly because the terminology is very confusing. You have a single disk (hard disk or SSD) with three primary partitions in it (that are also three volumes, of which only one has a drive letter assigned, C: ), which is a "fixed" device. The D: drive letter is assigned to the CD (or DVD) drive. (removable, with no media inserted) The F: drive letter is assigned to some other device (SD or CF card reader). (removable, with no media inserted) In mountvol you have 5 entries (3+1+1=5), each with its own GUID (differing only on the 8th character, 5/6/7/f/a). Everything seems "normal" (exception made for the "some other device" that would normally get drive letter E:, but the assignment to F: could have been made manually or - possibly - during setup at a certain stage the E: was taken and thus the following F: was used for it). The GUIDs are compatible with a system installed around 15:24 of the 25th of May 2022. SInce you have only one drive letter assigned to a defragmentable volume, probably you have that "all disks" item in the defrag tool, but cannot say for sure. You can check yourself the GUIDs (also that of the "ghost" volume) using the uuid tool (use the -d switch to decode the GUID): https://soft.rubypdf.com/software/guidgen-ossp-uuid Then, you could check your registry in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices to see if the "ghost" drive GUID is listed in there. jaclaz