M-O-W

LBA mode is used so CHS values are unimportant. CHS code still resides within the driver to handle legacy drives that do not support LBA commands (and thus are likely to be far below any limits).That's how it should be, but when .2222 encounters certain mappings with e.g. 240 heads the wraparound occurs, hence .2225. I don't know what moronic code causes the CHS mapping to have such a strange side effect on the LBA access, but I know it does not happen in .2225. For further details please see the forum link above.

Moin, Wrong. It switches over to 48-bit LBA commands when accesses are made to and beyond the 256th billion physical sector.Hmm, what happens if a multi-sectors transfer starts just below and ends beyond 128GB? If this leads to the harddisk producing an error, would the original code be able to handle it? The data loss would be noticed much beyond the 128Gb barrier. Also, if you read the previous posts I have made in this thread, that data loss is statistically a rare occurrence and only applies to specific BIOSae and hardware configurations which are not very prominent.Well, not that rare. And it might even happen to bigger than 128GB disk if the BIOS decides to map them into something with 240 heads. Thus it is important to test not only for correct function around 128GB but also around 32GB. I just see a general warning, not a specific one about .2222 vs. .2225. Except in the cases where the user is in for an unpleasant surprise because (s)he 1) wasn't even aware that a 32GB problem existed on the drives already in the system 2) has not used a HD >32GB yet and happens to trigger the problem with the new >128GB HD 3) later on adds a HD whose mapping triggers the problem, not even aware that another HD, even smaller than 128GB, could lead to trouble when a working big HD already is present in the system - how long would it take said user to identify the .2222 code as the source of the problem? I'd rather be on the safe side. Especially if it's only a *slight* slowdown it's not worth taking the risk, and does anyone know what other fixes Microsoft built into the .2225? MOW

Moin, the 4.10.2222 can be quite dangerous. See http://www.pcreview.co.uk/forums/thread-1944044-2.php and http://www.partitionsupport.com/gb32-13.zip for explanation. In short: Microsoft chose to not admit version 2225 fixes not just the Phoenix BitShift bug but also a bug where certain mappings can cause the driver to have a wraparound at 32GB. Last week, a friend lost his system partition due to this bug when he filled the second partition over the (absolute) 32GB mark, overwriting the start of the system partition of the harddisk, completely trashing partition root sector and FAT (it is quite surprising how long 98SE kept running until it finally crashed ...). Also above mentioned gb32.exe showed 1000 identical sectors before and 0 after installing KB243450. This was on a Compaq Armada E700 (with latest BIOS 6h_0315.02) which unfortunately decided to use a 240 heads mapping on a 40GB disk. LLXX, as you stated earlier in this thread that your patch only jumps to the new code when a LBA48 harddisk is encountered, this would leave patched systems vulnerable to the wraparound bug if a drive between (slightly less than) 32GB and 128GB was used. If a user just plugged in another harddisk and start losing data, the problem could be very hard to detect as it is really counter-intuitive that a >128GB patched driver could have problems with drives between 32 and 128GB, so I'd recommend pulling the patch to .2222 completely or at least add a big fat-a** warning. Every system that can use .2222 should be able to run .2225 anyway. MfG MOW