jaclaz

Just for the record, a few years back I had a problem (with Registry) on a Win2K box, so that Explorer would not start (as SHELL). So, as a temporary fix, I installed a trial of AstonShell (COMMERCIAL). Once done that, I found that Explorer (as FILE MANAGER) did not work as well. So, again as a temporary fix, I adopted the Dimension File Manager, a very minimalistic filemanager. Since I am somewhat "old-school" and I always do my "file moving/copying/managing" in a NC compatible app, see OFM here: http://www.softpanorama.org/OFM/Paradigm/index.shtml http://www.rmonet.com/commander/ I found that combining the two of them I had BOTH an easy "visual" File Manager and a handy "advanced" one, so, even once I had the Registry fixed on that machine, I do like using them. Dimension File Manager can still be found here: http://www.aplusfreeware.com/categories/ut...lemanagers.html or here: http://www.tinyapps.org/file.html This should be its "successor": http://members.tripod.com/dj_tow/minex.htm http://members.tripod.com/dj_tow/files/MiniExplorer_03b.zip Some screenshots are here: http://www.boot-land.net/forums/index.php?...pic=95&st=2 jaclaz

Hallo, Ilko_t. Some updates, I was successful in booting recreated virtual hard disks from your previously posted files, so I can confirm that it must be something outside the bootsector/MBR. I doubt the above, sorry. Try resetting the usual, say first 100 sectors, to F6 and try formatting the stick under XP WITHOUT the Hitachi Microfilter Driver..... I just checked the files in your last post, and again, there is no reason in them why they shouldn't boot. A few ideas for you to test (for the FAT32 ones): 1) Try, after the WINNT32 (and thus on a stick that it is not booting) to copy over the bootsector a "BootSector_Before.dat" generated before (when the stick was booting ok) 2) Try changing the "spare" bootsectors found on sector 6 with a copy of the current one, theoretically if the two bootsectors 3) Check this: http://www.boot-land.net/forums/index.php?showtopic=1647 maybe from comparing the outputs of findpart with the various options on the stick "before" and "after" one could find some other difference that might matter jaclaz

(bolding is mine) This appears case 4. of FAQ #10: Besides the other consideration about speed, even if you format the stick as Superfloppy, such behaviour will NOT work for NT/2K/XP/2003 as NO ARCPATH is generated, the problem has been discussed at length on Dietmar's thread, but unfortunately no solution/workaround has been found (yet): http://www.911cd.net/forums//index.php?showtopic=14181 The only viable solution is (possibly) through the use of makebootfat "special" MBR, but it appears that noone ever tested this (or reported findings): http://www.911cd.net/forums//index.php?sho...13784&st=44 It seems like we are in some kind of CATCH22 here, noone with a "Superfloppy only" motherboard has the technical abilities/time/will to experiment, whilst noone that has the latter has a "Superfloppy only" motherboard to experiment with. jaclaz

Unfortunately, that may be a symptom the drive is "toasted". In some cases, the drives can be recovered. You will need to try (cannot say if it will be possible) to access it directly from direct \.\PHYSICALDRIVEx in order to possibly recover some data. If you already have a backup of the data, you can skip the above and use the appropriate "Recovery" or "Mass Production Tool" for that stick/controller. Have a look at these: http://www.911cd.net/forums//index.php?showtopic=17701 http://www.911cd.net/forums//index.php?sho...14292&st=20 http://www.911cd.net/forums//index.php?showtopic=15776 then, if you cannot find your USB Vid/Pid between those listed, post them here, I will see if I can find an appropriate utility or contact Kingston, they may be willing to send one to you. jaclaz

To (hopefully) clarify the matter: DOS 6.22 had a /s switch for FORMAT that did FOUR things (last three specific of the /s switch): 1) Formatted the filesystem (FAT16 only) 2) made a bootable partition bootsector invoking IO.SYS and MSDOS.SYS 3) copied IO.SYS as FIRST file in the partition 4) copied also the other "system files" MSDOS.SYS and COMMAND.COM DOS 7.x (aka Windows 9x/ME) had a /s switch that did exactly the same, with these changes: a. filesystem could be both FAT16 and FAT32 (starting from Windows 95 OSR 2) b. there is no more the need for IO.SYS to be first file in partition In all the above OS a hard disk needed to be partitioned by the FDISK command into one or more volume(s) before beiing able to use the FORMAT command. Starting from Windows NT: 1) there is no more the FDISK command but one needs to use Disk Management to partition drives 2) the format command has no more the /s switch, ANY partition formatted has a bootable bootsector, invoking NTLDR, and NO system files are copied to the partition by the format command. NT originally supported FAT16 and NTFS (an early version, need at least SP3 to access newer "Win2K" NTFS) Win2K, XP and Server 2003 support FAT16, FAT32 and NTFS natively. Specifically with your IDE "second" drive, you might find problems to boot from it, not because it is not bootable in itself, but because if you boot from it, it will get letter "C:\" shifting your normal drive letter assignments. There are a few workarounds for this, most notably using a "migrate.inf" file to "keep old settings" and/or use a loader like grub4dos to exchange hard disk order. Some info is given in these threads, that, though aimed to installing from a USB device, can be adapted to your situation: http://www.msfn.org/board/index.php?showtopic=81788&st=6 http://www.msfn.org/board/index.php?showtopic=61384&hl= Using a PE of some kind and WINNT32 is a good solution, as if you build the PE from XPSP2 the booted volume should get the X:\ letter. jaclaz

Nice , but if I may, the same can be made in "pure" batch, as long as data in the chosen column are integers. A quick example: file dirlist.cmd: @ECHO OFF SETLOCAL ENABLEEXTENSIONS dir /-C %1 | find /i "%~x1" >dir.txt file addsize.cmd @ECHO OFF SETLOCAL ENABLEEXTENSIONS SET TOTAL= rem SET COL=%1 rem SET FNAME=%2 FOR /F "tokens=%1" %%A in (%2) DO CALL :addsize %%A ECHO TOTAL is %TOTAL% GOTO :EOF :addsize rem SET size=%1 SET /A TOTAL=%TOTAL%+%1 GOTO :EOF (if data is "space" or "tab" separated, otherwise one needs to add a delims= statement in the FOR loop) Run: and then: jaclaz

Check this: http://nt4ref.zcm.com.au/usb.htm jaclaz

OK, first thing, SWITCH OFF that laptop and DO NOT switch it on again, every boot you make, any fiddling you make, anything you make on that hard disk lowers the possibility and amount of recovery. You need ANOTHER (desktop) PC and a IDE 2.5" to 3.5" adapter. Take the hard disk off the laptop and mount it to the desktop PC through the adapter as "slave". Make an image of the laptop HD AS IS saving it on the desktop PC hard disk, it is better if you make TWO such images. The image(s) must be made with a byte-by-byte or sector-by-sector imaging utility, some are listed here: http://www.msfn.org/board/index.php?showtopic=100299 Now try one of several data recovery utilities against the laptop hard disk. A list is here: http://www.msfn.org/board/index.php?showtopic=97759&hl= http://www.msfn.org/board/index.php?showtopic=84345&hl= Saving each time whatever has been recovered to the desktop hard disk. Once you have done with an utility, if you are not satisfied by results, restore the image to the laptop hard disk and start anew with another utility. Depending on the value you attribute to the data, you might want to contact a professional service, rates can go from "flat rates" of a few hundred dollars to several thousands, but all companies will give you for free or for a very small fee an exact estimate or you will be spending for the recovery. Next time, ask here for opinions/suggestions BEFORE resorting to your "the local computer 'whizz'" (unless he is really is a 'whizz', of course ). jaclaz

Links to the most relevant posts (link already given, here): http://www.boot-land.net/forums/index.php?...ic=2807&hl= are in this post : http://www.msfn.org/board/index.php?showtopic=99453&st=3 Last one is here: http://www.msfn.org/board/index.php?showto...1384&st=293 Eventually, and that means WHEN everything will be found to be working and it will be tested, ilko_t will publish a complete guide, but there is NO "road-map" established, it may happen in the next 15 days as well as in the next 15 months, this procedure is something experimental and everyone contributing to it do so in their spare time, so please, do not ask for a release date, just wait and check back once in a while or experiment with info already provided. Check this: http://www.msfn.org/board/index.php?showto...1384&st=273 By the way, it is rather amazing how at this moment the thread had 51,818 views and the number of people that have actually contributed or gave a useful feedback can be counted on fingers without taking one's shoes off.... To provide a solution that works on the most hardware we need some people that test the procedure on their hardware and report problems or success. jaclaz

It's my turn to take a few days off-line. @ilko_t Unfortunately I have no definite ideas at the moment. I have re-checked the MBR/bootsectors you posted, and though I had no time to completely test them in VM's, I have reinforced my "feeling" that something else might be involved in the non-booting problem. The only "strange" thing I have found is the number of reserved sectors on FAT16 formatted bootsector, 08, which is "normal" for FAT32, but that is normallly 01 for FAT16, at least on DOS and NT/2K formatted partitions, I need to try what happens under XP to make sure. I hope to have time to do so on my portable while on vacation. So, since the only other two things needed for booting (to an error message) are NTLDR/SETUPLDR.BIN and NTDETECT.COM, maybe there are some changes to them? Any other missing/wrong file should generate a definite error message. Please post the error message you got (if any) when NOT booting, it could help on pinning down where the problem might lie. The ideas by cdob, as always , make sense, it is possible that some part of WINNT32.EXE does not "recognize" the usage of the Filter, accessing the drive directly or whatever. Another thing you could try could be using instead of the Hitachi Filter, the dummydisk.sys driver from CodeProject: http://www.911cd.net/forums//index.php?sho...181&st=1954 jaclaz

Also you can try Uwe Sieber programs and info on DEVCON: http://www.uwe-sieber.de/usbstick_e.html http://www.uwe-sieber.de/usbdlm_e.html jaclaz

More simply, try to add to the batch you have: this: EXIT and remove the wpeutil line jaclaz

@ilko_t I had a preliminary view at the posted bootsectors and MBR, and I am really puzzled, as I can see no difference that can justify the booting/not booting. Maybe after all there is nothing connected to MBR/bootsector that causes this behaviour. I'll try building a couple of Virtual disks with those bootsectors and check them.... As cdob hinted, IMDISK, while being an exceptionally GOOD tool, is not suited to work with "full" HD images. You'd better shift, at least for this kind of testing to Ken Kato's VDK: http://chitchat.at.infoseek.co.jp/vmware/vdk.html (optionally using my pseudo-GUI for it) http://home.graffiti.net/jaclaz:graffiti.n...ts/VDM/vdm.html You will need to use .pln file descriptors for geometry of drive, see my posts here: http://forum.winimage.com/viewtopic.php?p=938 Fell free to ask at any time , whether I can help you or not in a timely fashion it depends on the amount of free time I can set aside for this , however, the more you study and learn and the more you will see how there is nothing "magic" about anything computer related, everything can be, before or later, tracked to a cause, and (hopefully) a workaround or fix, even for the queerest of "behaviours" can be found, if only the same thing could be applied to "real" world. jaclaz

What you need to do is connected to "ACL". This is a freeware tool to modify ACL's, but there are others: http://setacl.sourceforge.net/ jaclaz

I'll check the bootsectors and let you know. About re-running the batch, at first sight the only missing thing is a check for NOT duplicating the "Old Default" entry, it can be fixed allright, I'll do that and the other more general polishing as soon as I have time. The PRESETUP.CMD appears to me an excellent idea, one could also try a POSTSETUP.CMD, as you already posted, it's not easily found info on WHEN postsetup.cmd is processed, but it seems like it is executed at the same point of GuiRunOnce: http://blogs.msdn.com/pointofservice/ http://blogs.msdn.com/pointofservice/archi...stallation.aspx though it seems that it is called by setuplauncher.exe: http://msdn2.microsoft.com/en-us/library/ms912403.aspx Check this oldie too: http://www.msfn.org/board/index.php?showtopic=12566 (could we use devicesetpath.exe?) Or maybe we could use Fedit.exe: http://www.msfn.org/board/index.php?showtopic=48200&hl= to edit WINNT.SIF on the fly? jaclaz

However, no need to post a new thread: http://www.msfn.org/board/index.php?showtopic=102383&hl= jaclaz

Well, maybe yes, the problem might derive from the fact that, as has been reported by Dietmar on the famous Full XP on USB thread on 911CD, some utilities (NOT the HP one ) could try to interpret data already on MBR and/or bootsector. This is has been reported for XP's FORMAT command (in other words a partition formatted with XP's tools from scratch on a blank 00's or F6's drive may be different from one created over a previously existing one, as XP's FORMAT comand may "inherit" some of the previous data). This has been proved beyond any doubt for floppies: http://www.denispetrov.com/format144/ but about hard disks/USB devices I have no definite proof. So the problem might arise by a combination of the previous format with the new tool used. We can search for a file and set the variable to the drive where the file is found, using "binifix.cmd" or another "tagfile" just like the common "WIN51.IP" is used in Windows Setup, but still we need a minimal batchfile in %systemdrive% or in another path for which an environment variable is already established. Try the following add this one liner (save it as CHECKVAR.CMD): SET >CHECKVAR.TXT put it in \System32 and add this in winnt.sif: You should get a CHECKVAR.TXT file with all Environment Variables already SET when [GuiRunOnce] is run. We can even make a self-deleting batch, though it's a bit tricky, it can be done. I'll think some more about this issue and see if I can come out with and idea. jaclaz

I'll look at it, maybe some "paths" are incorrect. EDIT: My bad, just temporarily change in the batch this: :WriteBootIni CALL :attribs %source% Copy boot.txt %source% del boot.txt ATTRIB !switches! %source%>nul GOTO :EOF to this: :WriteBootIni CALL :attribs %source% Copy %BOOTTXT% %source% del %BOOTTXT% ATTRIB !switches! %source%>nul GOTO :EOF I'll re-check the batch and add a kind of error check for this in next release. It could be some kind of "glitch" in the FORMAT command. I am sorry to say so, but to help in this I need you to do a lot of work , I need 2x2x2x3 series of bootsectors AND MBR's: 1) Bootsector FAT16 made by HP utility+MBR 2) Bootsector FAT16 made by PEto USB+MBR 3) Bootsector FAT 16 made by FORMAT with Hitachi filter+MBR (made with Disk Management?) same as above FAT32 same as above FAT16 and FAT32 after the WINNT32 execution Now, ALL the above but using BEFORE 1) 2) and 3) a hex editor or a direct disk access utility like dsfo/dsfi to write hex value F6 to first 100 sectors of the stick. jaclaz

Should be this one: http://filehippo.com/download_universal_extractor/tech/?1882 jaclaz

The only reason I can see is that if some kind of error is found, instead of the default message: this one is shown: Maybe it is derived by our "unconventional" method , maybe setup "senses" that the USB stick is a Removable device and changes the bootsector to one "appropriate" for this kind of devices. All other changes, as detailed in the .xls files are consequence of the different length of this message. However, the "After" bootsectors appear to be valid so I would not worry too much about it. jaclaz

@ilko_t Checked the bootsectors, NO problems, everything is cool, results attached in a .xls file. However you lied to me You did not use the SAME procedure with FAT16 and FAT32, as the bootsectors in FAT16 have a different Volume Serial, whilst the ones in FAT32 have the same one. There must have been a FORMAT between "snapshotting" FAT16_BootSector_Before.dat and FAT16_BootSector_After.dat (I won't believe that the same operation happened with FAT32 ones and the semi-random routine that calculates Volume Serial gave two times the same number ) jaclaz compare_bs.zip

Please find attached binifix4.cmd I made a few changes, now it should do everything needed: 1) If you invoke it without parameters it will ECHO usage instructions and ask for a drive letter 2) It will take current "default" entry and add it to the end of the newly made boot.ini editing the description from, say: to Let me know if it works for you the expected way. Also, once it is confirmed to be working, we could delete the "YES" confirmation, add something like a "/noold" parameter to avoid the [OLD Default] entry, and suppress "informative" messages. jaclaz binifix4.zip

Yep, you did not , that method is using DOS + WINNT.EXE, this thread is related to direct install. A slightly different DOS + WINNT.EXE howto is here: http://www.911cd.net/forums//index.php?sho...c=16713&hl= jaclaz

ilko_t Welcome back! No, I was waiting for you to get back, I'll do it in the next few days. About drive letter, it can ALREADY be given as a parameter, as in binifix3.cmd C: though there is no real (at the moment) parameter checking routine, the hardcoded "W" is just for testing, BOOT.INI should always be on the C: drive, at the time the batch is run. jaclaz

I too used to call mine Sarah, but, besides the fact that it evidently did not understand it's name as it invariably failed to come to me when I called it aloud, my wife began thinking I was: a. mad b. having an affair with another woman So I quitted. jaclaz