jaclaz

It seems more like *something else*, offset 8000 is within the 32,768 leading (normally) empty bytes/16 sectors, there would be no reason to have part of them filled with spaces, around the volume label (I presume you mean the volume descriptor, i.e. "CD001") could well be something like a fixed length field filled with trailing spaces. I have no idea what "Smart Storage, Inc." could be related to, Ultraiso is a known tool that may well be not fully compliant to specs (and actually I seem to remember a few issues with it when using it to edit a .iso) I have no experience with Gear software. An easy test that you can try is zeroing the first 32,768 bytes of a copy of a (non-working) .iso and see if it still misbehaves. Also, checking the actual .iso files with isoinfo (from the cdrtools package) might (or might not) find some particular inconsistency in those not working files. Cdrtools port to windows should be available here: https://sourceforge.net/projects/cdrtfe/files/tools/binaries/cdrtools/ jaclaz

It is strange, but I am not sure to understand. 20 means "space" in ASCII and "20,00" means "unicode space", neither are used as "empty" (which remains 00 or 00,00), this is not related to ISO (ISO 9660) file format, AFAIK. I have never seen a .iso where 20 is used for empty sectors (if this is what you mean)[1]. What would happen with a .txt file filled with spaces (either ASCII or Unicode)? Or, if you prefer, what happens if you change the file extension from .iso to <something else>? jaclaz [1] the standard has the first 16 sectors (2048 byte each, i.e. 32,768 bytes) "unused" or - maybe better - "reserved for other uses", they are (for normal CD/DVD images) all 00's or (as an example) have a MBR or other data for "hybrid" images, though it could probably be fine according to the standard to fill this area with 20 hex, it never happened to me to find one such .iso image and it would anyway make very little sense.

Personally (JFYI) I use (an old version of) Cute PDF writer for that (needs Ghostscript installed, that is anyway an useful tool). But AFAIK/AFAICR it doesn't need a service running, it appears as a normal printer in the print dialog. jaclaz

And if I may, a crappy article, with a (intentionally I believe, to gain traction/clicks) misleading title. The XP 2022 is only a mock up of what a non-existing OS may look like, this crap should be NOT reposted, especially on a technical board like MSFN is (or should be, or was until the recent trend by one or a few users to submerge it with random articles about anything they find or crosses their mind ). jaclaz

It could well be that all TTL devices are not suitable, or you are connecting them improperly, or whatever else, but if we assume that at least one of them works and connections are fine, the PCB is most probably defective or bricked beyond what you can do. I see you have asked where to look for professional repair : https://msfn.org/board/topic/184610-where-to-send-drives-for-repair/#comment-1242291 It is very difficult to give a suggestion, there are a few large firms, besides smaller (that could be either better or worse) shops. Seagate has their own data recovery service: https://www.seagate.com/products/rescue-data-recovery/ Drivesavers seems to have a lab in Houston: https://drivesaversdatarecovery.com/cms-category/location/ jaclaz

I seem to remember that the 7200.12 boards work when completely detached from the head and motors. You could try (after searching and verifying the above) to connect to the unmounted PCB and see if you get a terminal response. Shorting the pins is - again if I recall correctly - not used if the terminal does not connect/respond, but rather when the terminal continuously outputs an error message (a sort of loop) and the shorting allows to interrupt the loop. On other models the two points to short correspond to the head read channel, here is some info: https://msfn.org/board/topic/157329-barracuda-lp-no-not-a-720011-nor-a-720012/?do=findComment&comment=1003759 But I have no specific, let alone surely working, info/details. 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