dencorso

You're welcome! Now, don't delay before installing BHDD31. It'll keep your 500GB partition safe. Your case falls under my "Case One", so it's quite simple to get on the safe side. And from BHDD31 you'll get a DOS SCANDISK.EXE (from Win ME) which is able to work correctly with your big partition as well. And in what regards all the info in my Index thread, I guess the most relevant to you right now is my post #5 in thead j. But just to sum it up here for your specific case: (i) The DOS programs NDD.EXE and SCANDISK.EXE work OK up to about a 1 TB partition, at least (yet, SCANDISK.EXE is much faster). (ii) The DOS programs FORMAT.COM and FDISK.EXE work OK up to a 500 GB partition. (iii) The windows programs DEFRAG.EXE and SCANDSKW.EXE (both depend on DISKMAINT.DLL) work OK with partitions of slightly above 850 GB. And NDD32.EXE is limited to slightly above 250 GB (and I split my own 500GB disk in two 250GB partitions because of this). Yet, I strongly recommend you the Ranish Partition Manager (part244.exe) for partitioning and formatting big partitions in IDE HDDs. And I do recommend also that you do your defragging with JKDefrag, under Win 2k, unless you decide to use partitions of 400GB or less. Observe that this size limitation of SCANDSKW and DEFRAG has nothing to do with 48-bit LBA support. After installing BHDD31 you'll have full 48-bit LBA support from ESDI_506.PDR.

No. The more important question is how to modify CDFS driver to recognise multisession DVDs! @'Marius '95: IMHO, the best way to access all sessions in a multisession optical medium (be it CD or DVD) is by using IsoBuster. If, however, you really wish to have this option as a Windows Explorer feature, you may try the NERO shell extension, neroshx.dll (preferably v. 5.5.0.4), which is part of Nero 5. It adds a tab in the Properties in the right-click menu, that gives access to any session in a multisession disk, one at a time. In my experience it also causes many Explorer crashes, now and then, but works OK, when it doesn't crash. I always remove it from my installations of Nero, because of this instability it causes. On the other hand, multisession DVDs are said to be more prone to problems than multisession CDs, for any given OS, though, AFAIK. I've used my fair share of multisession CDs, way back when, but I confess I have no first-hand experience with multisession DVDs. Today the media is reasonably cheap to my taste, so I now cling to burning single-session, closed at the end, ISO 9660 (with Joliet) optical media, as a rule. @Drugwash: the problem is what M$ calls a "cosmetic issue" in that the CDFS driver works otherwise correctly, but does report the wrong size when asked. It may require a considerable amount of reverse engeneering to pinpoint and correct. Then again, with some luck, it may yield to a simple patch. I really don't know, but I'll investigate it more closely as soon as I can.

Maybe a single, clear thread summing up the contents (not an index of the threads)? [snip] I find not realistic that a newbie will read 791 posts/45 pages, understand everything in them without having to study and understand more concepts (that are often referenced to as "assumed" by the experts ), and succeeds at first try on a production system. [somewhat_offtopic] Sure. I'm facing the selfsame problem, perhaps a little bigger, trying to make sense of posts galore (I just cannot force myself to count 'em up, sorry), scattered over many threads and over at least three forums, in the hopes I eventually will be able to make the "XP Kansas City Shuffle" work for my board and USB drives... I've already learned a lot, but there still is much more to go... There is nothing as sobering as a face-first tumble down into ice-cold reality: Welcome to the desert of the real! [/somewhat_offtopic] I've reserved the second post because I intend to do just that. Sort of. ASAP. [Later Edit:] Here is the link to the Mini How-To, now located on the post #2 of my Index thread.

I'm quite happy to oblige! If working flawlessly and being freeware is not enough for you, what more do you want from LLXX's patched files to consider them worthy of using? M$ blessings perhaps? Let's point people to the info, not perpetrate unwarranted misinformation, please! Big HDD & 48-bit LBA Thread Index, On using HDDs larger than 137 GB (128 GiB) with Win 9x/ME

Micro How-To =========== Case One: One already has Win 9x working, out of a <137GB disk, and simply wants to add another >137GB IDE HDD, as a second disk, not as system disk: 1) Grab and install BHDD31.ZIP. 2) Reboot. Win 9x now has 48-bit LBA support. 3) Add new (Big) HDD. Partition and format it with The Ranish Partition Manager. 4) Get back to Win 9x and enjoy it! Case Two: One already has Win 9x working, out of a <137GB disk, and simply wants to substitute it for a >137GB IDE HDD, as system disk: 1) Grab and install BHDD31.ZIP. 2) Reboot. Win 9x now has 48-bit LBA support. 3) Clone the boot partition of the old disk to the boot partition of the new one. 3) Swap the disks. 4) Get back to Win 9x and enjoy it! Case Three: One wishes to do a fresh install on a >137GB IDE HDD, using the original Windows Install CD. 1) Partition and format the HDD with The Ranish Partition Manager. 2) Start windows install and *turn off* the machine at the point when it starts to reboot into Win 9x. 3) Boot to DOS from a diskette and substitute the file ESDI_506.PDR found at C:\WINDOWS\SYSTEM\IOSUBSYS by the updated one, grabbed from inside BHDD31.ZIP. Win 9x now has 48-bit LBA support. 4) Resume windows install. 5) After it finishes install BHDD31.ZIP, to update the other programs. 6) Get back to Win 9x and enjoy it! Case Four: One wishes to do a fresh install on a >137GB IDE HDD, using a modified Windows Install CD. 1) Copy the contents of your Windows 98 install CD to a folder in your HDD. (Let's use D:\98CD\ as an example.) 2) Extract the contents of BHDD31.ZIP to D:\98CD\Win98. (Extracting !read.me, _bighdd.inf, _install.bat and xxFiles.txt isn't necessary.) 3) Extract the boot sector from the original install CD using IsoBuster or UltraISO. 4) Burn the contents of D:\98CD\ to CD or CD-R with your favorite CD burning program. (Don't forget to make your CD bootable with the boot sector you just extracted!) 5) Partition and format the HDD with The Ranish Partition Manager. 6) Install Windows 98 from CD like you would normally do. 7) Get back to Win 9x and enjoy it! [thanks to TooMuchFreeTime, original version in post #7] Some relevant Q&A: =============== 1. Correct 2. Correct 3. If you connect the SATA Drive to the Motherboard with a SATA - PATA adapter then the same issue applies. If you use an add-on PCI Card then the Card BIOS determines support.

MSFN Threads: ========== 137GB limit - ESDI_506.PDR and other limits, Technical background and ideasEnable48BitLBA | Break the 137Gb barrierCorrected FDISK and FORMATLocalized Q311561New Scan disk and defragger for 98Windows 98SE LBA-48 Scandisk Replacement?Problems with 1 TB RAID, Format (DOS, Windows) doesn't work properly!Install w98 on Large Drives (Above the 137Gb Barrier)using a 500 G external HDD ... pre-formatted for XP-Vistahdd size limits? for ME defragger in MDGx' 98SE2ME, running 98seSP21 with 48-bit lba patchMax. partition size for 2k's CHKDSK and defrag?nforce 4 sata + esdi_506Using big USB HDDs with Win 9x/ME (0.5 TiB or larger HDDs)250 GB on a legacy motherboardQuestion about esdi_506.pdr version 4.10.2226 from Microsoft, What did it fix?FDISK and FORMAT large HDDsOther Useful Links ============ Maximus-Decim's BHDD31 (a. k. a. BHDD31e) MSKB Q311561 MSKB Q280737 MSKB Q263044 48bitLBA.com Via's SerialATA_V220E.zip (direct download) RLoew's Software Homepage The Ranish Partition Manager Free FDISK v. 1.2.1 (direct download)

@Drugwash: Well, seeing you're back to the forum, I believe now is the time to resume our unfinished discussion... CDFS and UDF are just two alternative filesystems. They are not, in themselves, neither good nor bad, and the choice of using one instead of the other falls on the one who burns the media. The choice is similar to FAT vs. NTFS: one can line up endless arguments either pro or against each filesystem but the issue is intrinsically unresolvable because neither is clearly better or worse, they are just different, and each has its fortes and also has weak points. Having said this, I'd like to point out that CDFS was originally devised for data storage in CDs (because DVDs and latter media did not exist at that time) and is very well suited for that use, even when applied to DVDs or possibly Blu-Rays. The original standard music CDs (from 1980 up to the present) use almost no filesystem at all, the Red Book standard being more of a mapping of the mechanical LP concepts onto the (then) new media (the CD). On the other hand, UDF was devised both for data storage and for Video storage, but with this latter use as the main object for its definition. So, while retail music CDs have just an embryonic filesystem, video DVDs are (AFAIK always) recorded using UDF, so as to permit the multiple features a commercial DVD usually exhibit. And, in what regards CDFS, at least in my view, it is the best choice for data storage optical media for almost all uses because it has widespread compatibility and is simpler. Then again, be warned that I favor FAT over NTFS for almost all uses also. The exception being if one *insists* on using files bigger than (4 GiB - 1 byte). Bear in mind that FAT and NTFS were devised for random access media, so using them on optical media entails a lot of useless overhead because these media are squential access only, no matter how fast. If you look closely at it CDFS is even simpler than the venerable CP/M filesystem, although, at the end of the day, both are little more than just a root directory and its bunch of files. And, IMHO, that's the beauty of it.

So, I was misinformed. Bad news indeed. So much for my last hopes... Well, your info settles it, Queue. There's no chance of us getting a better NDD32 for 9x/ME. And on the basis of what I reported some posts above, for partitions above about 250 GB, SCANDSKW can be used to check the file system, but to do a surface test the DOS utilities SCANDISK or NDD are the only way to go. Thanks a lot, Queue! You rock.

Thanks for your good work, Queue! We now know for sure that, up to now, no existing version of NDD32 is able to handle Big Partitions (with more than about 250 GB). But there is a very thin chance that a better version may yet come out because, AFAIK, 19.0.1.8 is the version reported by some of the files in the latest 2008 update to NSW. It is offered for owners of NSW 2006/7/8 and effectively updates their NSW to the latest version available. We don't really know whether v. 20.x.x.x and later work with 9x or not simply because they're not out yet, or am I much misinformed?

You may also like ImgView... It's freeware (from the time all PC Mag Utils were freeware).

MDGx is correct. There are no newer versions than the one from 2002. It was included in many later packages, the latest being NSW 2005, if I'm not mistaken. In any case, the four DOS utilities (DISKEDIT, NDD, UNERASE and UNFORMAT) accept the /version switch. And although they refuse to do any other work under windows, you can run them with the /version switch from a DOS box and they will tell you their version, even under windows. The latest ndd.exe, run in a DOS box, gives this output:

Thanks a lot, RetroOS! You rock! I've grabbed the patches and shall patch my NSW in the next few days, after my next back-up. But I have no way to repeat my tests just now, because the 32 GB pen drive is being heavily used in other projects. As soon as I can I'll get back to it, though.

I confirm NUSB 3.3 works OK with USB HDDs up to 500GB (I've tested two different drives). Bigger HDDs may also work OK, but I don't have access to any to be able to test it. Win 9x/ME works OK with a single 500GB partition also. But various apps refuse to work with partitions bigger than 250GB. Read this thread and the links therein.

True! Here: NVidia drivers 82.69, suddenly!@raandjegraham: Welcome to the Win 9x/ME forums! Hope you enjoy your stay and solve your issues!

My condolences, Drugwash. Well, it's not quite the CD driver, but the CDFS driver. So, it's just right to use it for a CDFS medium, be it a CD or a DVD. But, when the original CDFS driver was written, the programmer assumed no CDFS medium would ever be greater than 2 GiB, and that unfortunate assumption became a bug when CDFS DVDs became available.

No. Sorry!

Sure. I agree it's not the same issue, since it affects a ToolTip and not the Properties Tab. But it is the only mention in the MSKB to the peculiar number 2,147,450,880, which, BTW, can be written [(2^31) - (2^15)]. Now this number seems appear as the upper limit, in some MSVC, MSVB and .NET implementations, for the Int32 C data type, instead of the correct [(2^31) -1] = 2,147,483,647 limit, as defined in the C standard. What crossed my mind is that both bugs probably arrise from the overflow of (MS implemented) Int32 variables, and, just in this general sense, they have a common origin.But I was also imagining the CD/DVD bug would be higher up, probably in KRNL386.EXE or in Kernel32.DLL. In this you've just proven me wrong. It must lie inside CDFS.VxD, as you have now convincingly demonstrated. I do confirm your findings. I grabbed a random commercial printed DVD (Hell Freezes Over, by The Eagles) and put it in the tray. As soon as it was mounted, the Properties Tab in Windows Explorer showed "6,519,816,192 bytes (6.07GB)", and "File System: UDF", which is correct (it is a Dual Layer DVD). BTW, UDF, in Win 9x/ME, is implemented rather unusually: its driver is not at ...\IOSUBSYS\ as might be expected. It is UDF.VxD, which is part of VMM32.VxD in a plain vanilla installation, so it's not usually findable by a system search. But users of fully up-to-date Win 98SE can find it in %windir%\system\VMM32\ as the hotfix v. 4.10.2223 of UDF.VxD, which is installed by Q310695 ("DVD Player Program Cannot Access Data"). There is an equivalent hotfix (v. 4.90.3001) for Win ME. The Win ME version of Q310695 works OK in Win ME and can be ported to Win 98SE, but it does not work as expected with Win 98SE, as is usual for .VxDs from ...\VMM32\. Good luck with the patcher! It can be pretty handy to have a windows based, .PAT driven, generic patcher. Count on me to test it from your earliest working versions.

Hi, lightning slinger!Way back when, Petr had found out that it's possible to substitute DISKTSD.VxD from the File Manager. Your report makes me think all the VxDs in /IOSUSYS may be substituted in this way. Nice to know it. It really helps make my procedure a little less scary. Nice find! However, the new VxDs will start working only after a system reboot, so it remains necessary to reboot asap after the new files are all in place. Hi, Drugwash! Check it again, I guess you read the product version, instead of the file version... You surely are using v. 4.10.1999 If not, you've got a build I'm not aware of. Well, this is a known DVD related bug that remains unsolved. My system does the same. But it gives the correct size for CDs. My guess is the problem lies either with CDFS.VxD or VolTrack.VxD. But nobody knows it for sure, afaik. And no, sorry, these new patches don't solve this particular bug... So, yes, your configuration is OK.Later Edit: My guess turned out to be wrong! The problem is higher up, in the GUI part of windows, and affects anything treated as a "remote filesystem" (such as CDs, DVDs and remote shares)... See Q256576 Now, then, you can keep your configuration as it is, or you can fully upgrade it to the Win ME code base using the patches I just released and upgrading DiskVSD.VxD with the unofficial update available at MDGx's: Q271277. Just in case, here is some more info, thanks to the Wayback Machine: Q271277 and Q274175. The latter MSKB shows CDFS.VxD 4.90.3001 (the base for my 4.90.3002) addresses the same issue than 4.10.1999, so, here also, the main advantage is to move to a newer (and hopefully better) code-base. That would be great! Thanks! Perhaps the finding just reported by lightning slinger may be of help in creating the automated patcher, as it removes the need to go into true DOS and back, so its just one reboot instead of two. Thanks a lot to you both for your interest and prompt feedback! You rock! And Happy New Year once more! PS: I forgot to mention that these patched files should work with Win 98FE, 98FESP1 and 98SE (with or without 98SE2ME), afaik. I have conducted all my tests in a 98SE2ME system, and so did RetroOS, and that's why I didn't say this right away. But while the new patched files are still untested in Win 98FE and 98FESP1, all my previous patched VxDs from Win ME IOSUBSYS are already tested in the previous versions of 98 and do work in them OK.

CDFS.VXD (CDFS driver): If a media player is installed on the system, e.g., Winamp or Windows Media Player, audio CD files are shown in Windows Explorer as supported media files with the applicable program icon. WIN9x uses this file and files CDTSD.VXD and CDVSD.VXD to manage CD/DVD drives. CDTSD.VXD: A TSD is a type specific driver that handles the majority of drive calls for that class type(disk or cd) and then uses the spcific device adapter services to communicate with the hard disk. Primary responsibilities of a TSD include drive letter assignment and converting logical requests to physical requests so that the adapter driver can understand it. SCSI1HLP.VXD (SCSI I): Used by WIN9X to play video CDs in IDE CD drives. It is a filter driver just for SCSI I and some proprietary CD-ROM drives. This driver loads on boot and is unloaded if it is not needed. It is not used when communicating with SCSI II or SCSI III CD-ROM or hard disks. It allows Win9x to implement the SCSI I command sets in use by SCSI I CD-ROM drive models. VOLTRACK.VXD Volume Tracking Virtual Device Driver for I/O Devices (i.e. CD-Rom, Floppies, etc.). SMARTVSD.VXD Implements S.M.A.R.T. monitoring for internal IDE HDDs (PATA only). A VSD is a vendor specific driver, and may be used by a hardware manufacturer to help make his/her product more compatible with the ideal hardware expected by WIN9X. However, Microsoft supplied some generic VSDs for some devices, such as CDVSD.VXD, DISKVSD.VXD and this one. They usually are enough for most hardware, but in this specific case, if add-on HDD controllers are added to the system, the SMARTVSD.VXD should be substituted by another, customized to detect both the add-on card and the onboard controller(s). To have the most up-to-date code-base available. I think it's worth the effort, but that's just my opinion. Sure. I know my release method is complicated, but it was the best I was able to do. Now that the files are available, let's hope someone can come up with an automated patcher for them. I'm no good at creating installers, sorry! Yes, they can. 98SE2ME is not mandatory. But they fit well in 98SE2ME, so I think this is the proper thread for releasing them. Happy New Year to you all!

Five Additional Win ME VxDs Patched to Work with Win 98SE I've been testing them for a long time (from Dec 2007 to the present), and so has RetroOS (from Apr 2008 to the present; thanks RetroOS, you rock! ), so I'm quite sure they work as intended with Win 98SE. CDTSD.VxD, CDFS.VxD, SMARTVSD.VxD SCSI1HLP.VXD and VOLTRACK.VXD Warning: Read carefully the instructions below and only proceed if you are 100% sure you know what you're doing. These instructions do work, but a single small mistake can cripple your system!!! If your system stops booting, you have only yourself to blame. You have been warned! In case you are interested in using them in your system, here's what you have to do: *** BACKUP YOUR SYSTEM!!! *** Create a temporary folder and name it, say, NEWPAT Using 7-zip, WinRAR, WinZip or whatever your favorite file unpacker may be: Extract CDTSD.VxD, SMARTVSD.VxD SCSI1HLP.VXD and VOLTRACK.VXD from WIN_20.CAB, from your Win ME distribution disk and drop these files into NEWPAT; Extract CDFS.VxD from ME274175.EXE, which you have to download from MDGx's site, and drop it into NEWPAT; Extract all patch patterns from New_VxDs_PATs.7z, which is attached to this post, and drop it in NEWPAT; Extract PATCH.EXE from utils.zip, which you have to download from kanastacorp's site, and drop it into NEWPAT; If you don't already have it, extract GETVER.EXE from CmdLine.zip, which you have to download from lbrisar's site, and drop it into \%windir%\command\ folder (or just into NEWPAT if you don't intend to keep it); Open a DOS box, go to NEWPAT and run at the command prompt getver *.VXD It must show you all the .VxDs you've collected are version 4.90.0.3000, except for CDFS.VxD, which must be v. 4.90.0.3001 (if not, the something went wrong, recheck your previous steps). Now let's do the actual patching (it must be done as described, because PATCH.EXE does not accept, say, *.VXD) so, at the command prompt run: PATCH -p CDFS.VxD CDFS.PAT CDFS.NEW When the prompt reapears, run: PATCH -p CDTSD.VxD CDTSD.PAT CDTSD.NEW When the prompt reapears, run: PATCH -p SMARTVSD.VxD SMARTVSD.PAT SMARTVSD.NEW When the prompt reapears, run: PATCH -p SCSI1HLP.VxD SCSI1HLP.PAT SCSI1HLP.NEW When the prompt reapears, run: PATCH -p VOLTRACK.VxD VOLTRACK.PAT VOLTRACK.NEW When the prompt reapears, run: getver *.NEW It must show you all the .NEWs PATCH created are version 4.90.0.3001, except for CDFS.VxD, which must be v. 4.90.0.3002 (if not, the something went wrong, recheck your previous steps). When the prompt reapears, run: Copy *.NEW %windir%\system\iosubsys /b /v When the prompt reapears, close the DOS box. *** This is the hazardous part! Be careful. *** Restart in MS-DOS mode or boot into DOS from a BOOT diskette. Go to %windir%\system\iosubsys. Run a "dir *.NEW" command just to get the list of new files. Rename to .OLD each of the 5 old .VxDs, one at a time (e. g. "ren CDFS.VXD *.OLD) Run a "dir *.OLD" command just to check you now have 5 .OLD files corresponding to the 5 .NEW files you had as you started. Run "ren *.NEW *.VXD" Run a "dir *.NEW" command and now no file must be found, if everything went as it should. Restart windows. *** If windows doesn't start: Rename the five updated .VXDs back to .NEW and the files .OLD back to .VXD Now windows must boot again. Once back in windows, recheck your steps and try again. *** Once you're satisfied everything is working as it should, then you may delete the NEWPAT folder and all files inside it. Of course, as always, the standard disclaimer applies: It works great for me, but YMMV and I can guarantee nothing whatsoever about these patches, and about the use you make of them. So, by deciding to apply them you fully accept that anything you do is of YOUR SOLE RESPONSIBILITY... Hence, if after adding these files your pc morphs into a purple mushroom and explodes, causing a 10-day worldwide blackout in the process, you know you can't blame me for it! You have been warned. Kanastacorp's site is returning error #509 (= "Bandwidth Limit Exceeded") so I've uploaded their fundamental package here: utils.zip, for you to be able to get PATCH.EXE from it. A further warning: in case you have a third party SMARTVSD.VXD in your system, like the one installed with the PROMISE add-on PATA or SATA controllers, you must keep the third party SMARTVSD.VXD. So you should do all of the above procedure just for the other four files, and skip replacing SMARTVSD.VXD. New_VxDs_PATs.7z

I use Win 98SE with 98SE2ME and fully up-to-date. I never had any issue with versions 0.47 and 0.48 of eMule. Neither have I ever had any issue with version 0.49a. I updated to 0.49b two days ago and it kept crashing, more often than not. When I attempted to exit eMule, sometimes it worked, after a small delay, sometimes it froze windows, requiring a reboot, and sometimes it just caused a reboot right away. For now I've gone back to version 0.49a and all seems to be OK again. Has any of you experienced any issues with 0.49b?

Universal FASTFAT? Would that refer to the drivers mentioned by bearwindows? Read the "Solution 2" to "Problem 7" here. Also this thread may have some additional info.

Read Day-to-day running Win 9x/ME with more than 1 GiB RAM Merry X-mas to you and all our fellow members here at MSFN!

I've done even more tests:I've partitioned as a single active primary partition, using RPM (the Ranish Partition Manager), a Corsair Flash Voyager 32 GB pendrive. The partition was formated (with fat32format.exe, under Win XP) as FAT-32 with 02 sectors/cluster and, using all the space available in the pendrive, had 32,628,384,768 bytes (32,6 GB or 30.4 GiB), 31,863,657 clusters and 248,935 sectors/FAT. ScanDskW.EXE (the Win ME one, version 4.90.0.3000) was unable to check this partition and threw the following error message: "ScanDisk could not continue because your computer does not have enough available memory. If any other programs are running, quit one or more of them, and then try running ScanDisk again.", precisely as reported by Marius '95 to have happened when he tried to use ScanDskW with his own 1TB RAID. I've then reduced the size of the partiton progressively, and eventually created a 27.2 GB (25.4 GiB; 27,226,775,552 bytes) partition, with 1024 byte clusters, which had about 26.6 million clusters (26,588,648 clusters) and 207,724 sectors per fat and then a 27.0 GB (25.2 GiB; 27,022,737,408 bytes) partition, also with 1 kiB clusters, which had about 26.4 million clusters (26,389,392 clusters) and 206,168 sectors per FAT. ScanDskW.EXE (v. 4.90.0.3000) worked OK with the latter (taking, however, 6h to finish!), but threw the same error message reproduced above with the former. So it seems that the limit for ScanDskW, at least for my own computer/OS-configuration, is somewhere between 26.4 and 26.6 million clusters, or somewhere between 206.1 and 207.7 thousand sectors per FAT. This result confirms Marius '95 report and seems to disprove the result reported by 98-Guy. Yet, things might be more complicated than this. The tests conducted by 98-Guy were very careful and well designed, so I do believe he managed to use successfully ScanDskW with a partition of 31.2 million clusters... The facts are that ScanDskW throws an out-of-memory error and ScanDskW is a 16-bit executable windows program (that is: a NE executable), and all such programs run together with the system dlls and the 16-bit part of windows kernel in the 1-GiB-wide arena begining at the virtual address 2 GiB, that Microsoft call the "Shared Area" (see Q125691), and, hence, it is reasonable to imagine that the more cluttered this arena may be, the less space remains for ScanDskW to run... and my guess is that 98-Guy's test system had a far less cluttered Shared Arena than my day-to-day-use system, which is what I've used for my tests. But, in any case, while it may be possible to make it work with 31.2 million clusters is some special situations, the more usual limit of about 26 million clusters or even somewhat less than this should be the one to have in mind, when thinking about ScanDskW usability, in the general case. As a side note, when working with more than 25 million clusters, ScanDskW slows the system to a crawl and prevents one from loading almost any additional program before it finishes, so that it virtually works as if the system were an one-task-at-a-time environment. On the other hand, DOS is a true one-task-at-a-time environment and both scandisk.exe or ndd.exe, running in DOS, checked my initial 32.6 GB pendrive partition in about 30 min each. So, whether or not ScanDskW runs with such 25-million-clusters-or-more partitions or not is less of an issue, because if one has to run it as if standalone, it is much more convenient and fast to reboot in DOS, scan the partition of interest with any of the mentioned above DOS programs, and reboot in windows once again. On the other hand, it is relatively fast to check just the file-system integrity (do the standard test) with ScanDskW, up to the cluster-number in which the out-of-memory errors begin to appear. What I think is definitely a no-no is the surface scan (a.k.a. "thorough test"), which, as I said, takes some 6h to complete.

I answered that question here. If you wish to have a full view of the history behind the version numbers conundrum, and have time for it, do read the whole original LLXX topic.