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

That is probably a 0x0000007b STOP error, "Inaccessible boot device" which means - more or less - that somehow you lack the proper drivers for the internal mass storage device (SATA). It is "strange" as if you have the controller set as IDE compatibility mode in BIOS you shouldn't need any particular driver, so, it may be that (or another error) connected to the ACPI, or more generally to other chipset drivers. The howto/instructions by Jakob99 is seemingly far more complex (and in parts not at all understandable - by me) then just overwriting ACPI.SYS with a modded version, I have no idea why, but it seems like the ACPI.SYS is replaced twice, both in the .cab and then again in the installed OS. Maybe you could try ask for clarifications on that thread. I don't think that the variant (Datacenter vs. Workstation ) makes any difference. If the issue is only related to the SATA (or however internal hard disk/SSD) you may try using SVBUS and a VHD (but it is not easy/straightforward): http://reboot.pro/topic/21787-svbus-virtual-scsi-host-adapter-for-grub4dos/ https://github.com/grub4dos/svbus/blob/master/ReadMe.txt jaclaz

Strange: https://www.wikihow.com/Defrag-Windows-7 I am not sure I understand what you mean by "UNC names"? Mountvol shows GUIDs, diskpart (AFAICR) shows neither UNC nor GUID. jaclaz

@legacyfan I think there is some misunderstanding going on. The present thread is perfectly fine, and you need not to apologize for your posts in it, you had a (real) technical problem and asked for help, which led to some related discussions on the methods used or usable. This is exactly the main scope of MSFN, to exchange ideas, knowledge, opinions mainly on (computer related) technical themes. jaclaz

BUT, once you will have the discs you will be playing another game (suggested by Dietmar), not this one. jaclaz