jaclaz

Sure, as the guy that provided it commented, for four PC's that is fine. The FOR /L loop utility becomes evident when you have the whole range 1÷255 to scan or more... ... and the "points adding system" may come of use when (if) you need to add some other condition (like -say - a Ping result that is good but that has a too high TTL or response time) ... jaclaz

Well, try again, after having deleted mycurrent.bss (you didn't actually dsfo a "really current" mycurrent.bss, as there was already an existing file and dsfo never overwrites a target). It's likely that even with the "really current" one there will be no differences, but if we check, let's actually check . jaclaz

Something like: http://ss64.com/nt/ping.html jaclaz

ZEUS, with all due respect , you don't have one of those people called "friends" or "relatives" with a paypal account that may be willing to make the donation in your name? Is having the watermark (and/or the periodical nagging) so unbearable? (or, if you prefer, is having Aero Glass so *needed* that you can't bear a few days/weeks without it?) jaclaz

Well, just for the record, nano98 is a (BTW nice) POC (Proof Of Concept) and nothing more than that, it has no practical use as it simply misses too many files/subsystems, if you are going after a very reduced Win9x you'd better go for the Winimize (it can still be found through Wayback Machine): http://reboot.pro/forum/53-winimize/ More related projects here: http://www.911cd.net/forums//index.php?showtopic=12326 If useful , find attached nano3.zip. jaclaz donano3.zip

It should be indifferent (both the OS and the connection). The idea is just to check if - as your last output indicates - the bootsector of the volume is currently the "as512" one. If it is and if the volume does not mount on the 512 bytes/sector connectoion (the eSata) it means that *something else*) the actual values inside the bootsecotr or in the EPBR are "wrong". jaclaz

Unfortunately jaclaz would say that you FIRST make a dd-like or "forensic sound" image of the whole disk, and ONLY later you fiddle with the disk to (hopefully) try and fix the partiion or filesystem on it. jaclaz is notoriously grumpy and won't negotiate on this basic, preliminary step. Of course you could lie and post that you already have made an image even if it is not true . But you risk that jaclaz may suggest you a destructive procedure (by mistake or intentionally ) and you would lose your data. In any case, what you can do in the meantime is to re-run TESTDISK with a log and post (possibly compressing it into a .zip archive) the actual log. Still, you need 2 (two) disks of suitable size, one to host the image (which means a 1.5 Tb disk) and another disk of similar size to the problematic one, i.e. 1 Tb. Right now we have no idea if the blackout/surge created a hardware error of some kind (which would be likely to create the " WinError 23: data error") or if the disk is "sound", and if you value your data, you should follow the standard procedure. If you do not have enough money right now to afford buying the two disk drives, it is better if you leave the failed disk alone, WITHOUT ANY further attempt to recover it until you have saved enough money to buy them (and even if your original hard disk can be recovered "in place" and "fully" you can put these twqo addtional disk drives to good use, by using them as backup media). I will re-state how a backup is not an option, it is a BASIC *need*. jaclaz

Maybe you (actually the source) is missing the BOOTMGR (as the message says). There must be (for BIOS booting) a BOOTMGR file in the root of the .iso. jaclaz

http://hddguru.com/software/2005.10.02-MHDD/mhdd_manual.en.html jaclaz

Which EXACT set of instructions? Which EXACT USB (or serial) to TTL converter? "Seems" or "is" in BSY state? Check and make sure: http://www.msfn.org/board/topic/129263-instructions-for-checking-if-your-drive-is-set-to-busy-state/ In case of doubt, FORGET anything you have read ANYWHERE and ONLY try following CarterInCanada´s guide: http://www.msfn.org/board/topic/133387-debricking-the-seagate-drives/ jaclaz

Actually I am out, I'll be back in a few days, but apart the possibility that dencoso pointed out, the behaviour under XP is "not normal", In other words it is possible that *something* is wrong in the values written to the "as512" bootsector (which should have been deployed correctly, at least on XP). As soon as I am back I will review the batches, veryifying the changes we introduced and adding a new batch to verify whether the correct bootsector has actually been written (and with the right values, though judging from what you posted on #121 they do seem right). What you can check in the meantime by doing, dsfo \\.\J: 0 4096 mycurrent.bss FC /B mycurrent.bss as512NTFS.bss is that the "as512" bootsector is currently the one on the drive, jaclaz

You mean on previous OS? To be fair, NO. The Registry association works by right clicking on the folder, what I personally use (on 2k and XP) is much more convenient, as it allows to open the cmd prompt inside the folder which is opened in Explorer, it is a .dll, Here: http://www.roggel.com/NGNeer/BackgroundCMD/index.shtml More here: http://www.msfn.org/board/topic/111384-util-or-shell-extension-to-have-dockable-cmd-bar-in-xp/ jaclaz

@Andrew T The "tiny unallocated volume" is "normal" along the partitioning scheme adopted by all MS OS's (up to Vista). There is the *need* (it is not an actual *need*, at least not since DOS 6.22 or possibly even 5.00, but like many legends has been "kept in use" for several years and for several OS releases) of aligning the end of a volume/partition to a whole Cylinder. This means that the last CHS address on a disk is n cylinders, and since a cylinder has (normally) 255 heads and each head 63 sectors, the net result is that you cannot have a partition smaller than 255*63=16065 sectors which multiplied by 512 equals 8,225,280 bytes, Since real disk geoimetries are not (since many, many years) connected with the n/255/63 geometry used in the CHS scheme, their size is almost never a multiple of 8,225,280, so a small "unused rest" always remains at the end of the disk (unless of course you create your partitions manually or with tools that allow to specify addresses in a more accurate way. If you check when you use disk manager or similar you will see how the size of the partitions go in steps of 8 Mb (and the above is the reason why this happens). jaclaz

It still seems to me like an issue with access to the target. The NTFS partition should start on sector 65536 (on a 512 bytes/sector) so you can try using the PhysicalDrive as target. Since 65535*512=33554432 that would be: dsfi \\.\Physicaldrive1 33554432 4096 as512NTFS.bss As a side note, do you have on both the machines a XP installed? I.e. can you try the switcher.cmd "as is" on a XP OS? (just to make sure that there is not *something* else besides this kind of "protection" on Windows 8.x) jaclaz

Well, Partinfo tends to be often more alarming than needed, but in this case it has it's good reasons. It seems like the only "valid" volume on that disk is the FAT 32 Primary partition in Entry/ #2 anyway, and even that one needs to be corrected (actually should as in "better if it is") in the CHS part. In other words the first two partition entries, #0 and #1 can be deleted, and it should remain only one entry in the MBR, in #2, as follows: 0C 963/195/1 1023/254/63 15,482,880 62,672,400 BTW, the fact that now the END CHS is 48/239/63 should mean that the partition was (badly) created on a machine with one of the "strange" BIOSes typically HP and Lenovo) that use 240 heads geometry the virtual END CHS for 15,482,880 + 62,672,400 is 4864/239/63 and while the writing of 48 in the field (where you cannot actually write 4864 because it maxes out at 1023) may well have been a glitch in the matrix, the size of the partition (that ends up on head 239) when analyzed on the "normal" 255 heads geometry is really "queer". If I try the same values with a 240 cylinder geometry, the CHS becomes 1024/0/1 5168/239/63. It seems like this partition is a dd copy of a volume created on a 240 heads BIOS machine and then *somehow* deployed to this disk. All in all the idea of restarting from scratch is not that bad, though it is possible to fix the situation, you would need a good partitioning/repartitioning tool to move the FAT32 where it should be and to enlarge it to respect Cylinder/Head boundaries (optional but advised). There is no reason why repartitioning the second disk this will affect the Win9x booting, but in case you can still use bootpart or grub4dos (or both) to fix the booting *any time*. jaclaz

Run the mountvol command. This more or less means to type the word "mountvol" (without quotes) on the command line and press the [Enter] key. jaclaz

Well, of course you will need to copy dsfo.exe from C:\MkPriLog\ to I:\ if you run the command from I:\ (which is fine BTW). From the FC results the sectors seem fine. So the issue seems the one about the volume bootsector being somehow "protected" and allowing not the write of the new bootsector. Try manually, running the Mountvol command. Check which volume has now (on the eSATA machine) the drive letter J:\. It will be something like: \\?\Volume{dcb73171-341c-11e3-b06c-001fc6bb76ce}\ copy and paste it *somewhere* (like a new .txt document). then run: mountvol J:\ /D this will remove the mounting point/drive letter from the volume. Then try writing manually the bootsector, that wii be: dsfi \\.\Volume{dcb73171-341c-11e3-b06c-001fc6bb76ce}\ 0 4096 as512NTFS.bss of course replace the Volume{dcb73171-341c-11e3-b06c-001fc6bb76ce}\ with the actual value you got. Please note how the question mark in \\?\ has been changed into a dot, i.e. \\.\ . Then run again mountvol, as: mountvol J:\ \\?\Volume{dcb73171-341c-11e3-b06c-001fc6bb76ce}\ to reassign the drive letter to the volume. Maybe that is the issue .... jaclaz

Are you sure you really meant "once" (and not "if") ? jaclaz

Maybe useful, maybe not, this should be a simpler batch: @ECHO OFFSETLOCAL ENABLEEXTENSIONSFOR /F "tokens=3,6 delims=: " %%A IN ('Handle ThemeSection') DO (ECHO handleid=%%BECHO Pid=%%AHandle -c %%B -p %%A -y)to the same effect which, provided that Command Extensions are enabled, could also be reduced to a oneliner: @FOR /F "tokens=3,6 delims=: " %%A IN ('Handle ThemeSection') DO Handle -c %%B -p %%A -yUNtested as I don't have a Windows 8/8.x or 10 install available. jaclaz

Well, with all due respect for edborg , in that thread he asked himself the "wrong" question and managed to get a "wrong" answer. What happened there was that he had an extended partition (LBA, type 0F) and that booting to grub4dos a ("wrong") menu.lst entry made that partition entry "hidden", changing it's type to 1F. All he had to do (in that case) would have been to change back the partition type to 0F. Right now I have no idea in which situation is your disk, why don't you run partinfo and provide a screenshot? http://www.msfn.org/board/topic/173016-triple-booting-windows-nt-4-98-and-2000/ http://www.msfn.org/board/topic/173016-triple-booting-windows-nt-4-98-and-2000/?p=1091850 (thread that might have BTW given some relevant info useful BEFORE you got into this ) Or run *any* tool showing the actual partition table layout? jaclaz

It's not that you have to explicit SETLOCAL ENABLEEXTENSIONS ? http://www.robvanderwoude.com/local.php http://www.robvanderwoude.com/ntfor.php jaclaz

Which "error message"? Does it come from the SFX engine or from the batch/command processor? jaclaz

Well, the first issue is then related to Mountvol needing to be run elevated, which we should be able to fix by going from to: But it is well possible that there is either an error in other parts of the batch or that the bootsector earlier created (for whatever reasons) has wrong values or has been deployed to a wrong address though this latter is improbable as the output of the batch is "as expected". What happens if you run again the switcher.cmd? In theory it could be run any number of times and prompt to switch only if "the other" bootsector is found. What happens if you put the whole disk offline and then bring it up online again? It is possible that this additional step is needed to "refresh" the view? Or maybe we are in this condition, where the bootsector is locked by the OS: http://reboot.pro/topic/8200-grubinstexe-write-failed-vista-ntfs-bootsector/ but it shouldn't happen for the bootsector. Or maybe it is better to revert the logic of the batch, right now it attempts to mount the volume assigning to it a driveletter and then deploys the bootsector, possibly it would be smarter/better to make sure that the volume is not mounted, deploy the bootsector and only then attempt to mount it. However, one thing at the time, let's first check if by any chance there is an issue with the bootsectors. Try running: fc /b as4kbNTFS.bss as512NTFS.bss and post the output. As well, get the "current" bootsector from the "J:" drive, that would be: dsfo \\.\J: 0 4096 mycurrent.bss and fc it against either of the two saved bootsectors. jaclaz

Good (I mean bad of course) . We will need to troubleshoot the switcher.cmd. On the USB machine you should be able to assign to it a drive letter manually, however. In the switcher.cmd, edit this: to The issue is likely to be in the previous code that attempts to use WMI and/or REG.EXE .... jaclaz

Yep , these three were the three in three years time I was referring to, but I seem to remember that there were also some slight differences for Windows 2003 drivers, possibly introduced with SP1 or SP2 (but cannot really say for sure), while I am pretty sure that for some reasons (but cannot really remember the specifics) I did keep some Windows 2000 Server installs because there were not available drivers for the 2003 and the 2k one's did not work (and thus went "forward compatibility" of the WDM's). To be fair I believe that - just like UEFI/GPT and their artificial or senseless incompatibilities - the main culprit in this case is more Intel than MS (but of course I may well be wrong). jaclaz