Jump to content

New old 2G file size bug


jds

Recommended Posts

FYI.

Well, here's a new one (well, I don't recall reading about this anywhere before).

I was investigating reliability of high-capacity Flash drives (I've experienced some occasional problems on my Medion USB stick where an 8K chunk within a file is junk; no errors reported when writing or later, when reading such files) and had copied a large ISO image [edit: I forgot to mention, it exceeded 2G] to my hard drive via Windows Explorer. This is on a W98SE system with the 2G Copy patch applied.

I then tried to run Charles Dye's CHKSUM utility to verify the file from it's CRC32 value. This reported "--------" for the CRC32 and "0005" for the XDIR checksum, and said that 1 error had been encountered while reading the file. Strange. What did this all mean?

Well, what it meant was that Runtime Error 5 (Access Denied) had been encountered when attempting to read the file. Yet, I had run the same CHKSUM utility on a Vista machine with the same file and it had worked OK there. So, the CHKSUM utility itself wasn't the problem.

I then tried other 16 bit applications to access the file in question, and all of them failed with Runtime Error 5 or Access Denied. Even trying the internal "copy" and "type" commands produced the same result.

Finally, I tried the same thing in pure DOS mode. Using MS-DOS 7.10, the same problem occurred. Using FreeDOS 1.0 (using the installation CD as a Live CD), no such problem.

So it seems there's a 2G file size problem in MS-DOS 7.10, which also seems to affect (or perhaps it's yet a separate problem?) all 16 bit applications running under W98SE.

Joe.

Link to comment
Share on other sites


Did the problem manifest itself in Win98SE, despite the presence of the patches listed in the quote below?

Check. Unofficial 'COPY2GB.EXE' and 'SHELL98.EXE' updates.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

Also how do FCIV.EXE and CRC.EXE behave, both on 98SE and pure DOS, with your problem file?

* CRC/MD5/SHA file (PE) checksum tools that work with 9x OSes [free(ware)]:

http://www.mdgx.com/xptoy.htm#CRC

Link to comment
Share on other sites

Did the problem manifest itself in Win98SE, despite the presence of the patches listed in the quote below?

Check. Unofficial 'COPY2GB.EXE' and 'SHELL98.EXE' updates.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

Also how do FCIV.EXE and CRC.EXE behave, both on 98SE and pure DOS, with your problem file?

* CRC/MD5/SHA file (PE) checksum tools that work with 9x OSes [free(ware)]:

http://www.mdgx.com/xptoy.htm#CRC

I have released my KERNEL32 2GiB Bug Fix Patch. This Patch supercedes the COPY2GB Patch as it supports all three Seek Modes unlike COPY2GB that supports only Seek from Beginning of File.

It is available free from my website rloew1.no-ip.com in the Prerelease and Beta Section.

Link to comment
Share on other sites

Did the problem manifest itself in Win98SE, despite the presence of the patches listed in the quote below?

Check. Unofficial 'COPY2GB.EXE' and 'SHELL98.EXE' updates.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

That's right, those patches are installed (except for 98KRNLUP, since my DLL's seem newer than this). I can copy the file via Windows Explorer and I can open it with HashCalc (SlavaSoft), but any 16 bit application, including COMMAND.COM (eg. 'copy' and 'type') seems to fail.

Also how do FCIV.EXE and CRC.EXE behave, both on 98SE and pure DOS, with your problem file?

* CRC/MD5/SHA file (PE) checksum tools that work with 9x OSes [free(ware)]:

http://www.mdgx.com/xptoy.htm#CRC

OK, downloaded these MS utilities and they work fine. However, these are 32 bit applications, so these go via the standard Windows functions that have the 2G patch, so that's to be expected.

I tried to induce CRC.EXE to work in pure DOS with the help of the HX Extender, but no luck. They really don't want to work at all in DOS, do you know a way? (Similarly for FCIV.EXE, although I didn't bother trying HX with that.)

BTW, don't forget that the 16 bit CHKSUM utility I use (sort of as a replacement for XDIR;-) worked with that large ISO image under FreeDOS (also under Vista), so the utility itself is fine.

I have released my KERNEL32 2GiB Bug Fix Patch. This Patch supercedes the COPY2GB Patch as it supports all three Seek Modes unlike COPY2GB that supports only Seek from Beginning of File.

It is available free from my website rloew1.no-ip.com in the Prerelease and Beta Section.

OK, I tried this and it didn't make a difference. Not surprising, since none of the things I tried would have had any reason to Seek other than from the beginning.

BTW, note that your patched DLL is build 4.10.2225, whereas the version I was using was 4.10.2226. (No idea what that extra build stepping gives.)

Joe.

Link to comment
Share on other sites

This is interesting, I never really thought about it. I used to maintain USB keys that booted and allowed for BIOS updates and using Ghost clients. Originally we used the Win98 bootfiles that is in every version of Windows format tool since 98, but had to go to DOS 7.1 in order for certain NDIS drivers to load properly. We didn't run into any problems with creating these keys until we tried 4GB and 8GB keys. All the normal ones were 1GB keys and they always worked fine. Now it seems that USB Keys under 4GB are becoming a rarity.

I never put 2 and 2 together and figured out why the 4GB+ USB Keys wouldn't boot into DOS 7.1 until I read this. If 1 and 2GB Keys end up going the way of the Altair, do you suppose there could be a way to fix this, at least for DOS 7.1?

Link to comment
Share on other sites

I have released my KERNEL32 2GiB Bug Fix Patch. This Patch supercedes the COPY2GB Patch as it supports all three Seek Modes unlike COPY2GB that supports only Seek from Beginning of File.

It is available free from my website rloew1.no-ip.com in the Prerelease and Beta Section.

Hi rloew...

I think there may be a bug in your KERNEL32 2GiB Bug Fix Patch...

Yesterday, I updated the old COPY2GB KERNEL32.DLL to your version...

When I went to use VideoReDo Plus (a video editing app), it kept crashing with an error involving msvcr80.dll...

Using Dependency Walker, it showed that msvcr80.dll is linked to KERNEL32.DLL...

I switched back to the old COPY2GB KERNEL32.DLL and after a reboot, VideoReDo Plus ran fine...

Just thought I'd let you know... :)

Link to comment
Share on other sites

OK, I tried this and it didn't make a difference. Not surprising, since none of the things I tried would have had any reason to Seek other than from the beginning.

BTW, note that your patched DLL is build 4.10.2225, whereas the version I was using was 4.10.2226. (No idea what that extra build stepping gives.)

Joe.

I don't know what applications use the other Seek Modes other than some of mine but there probably are some.

The underlying DLL is the same. The Author of COPY2GB bumped up the Version Number.

Link to comment
Share on other sites

RLoew is right, of course. The COPY2GB patched kernel32.dll v. 4.10.0.2226 is based on Microsoft's hotfix kernel32.dll v. 4.10.0.2225 (from KB320798).

Both LLXX and the anonymous patcher have produced patches derived from kernel32.dll v. 4.10.0.2225, just as RLoew did now. For the record, here's a link to the original thread this matter was discussed in. Thank you, RLoew, for looking into this matter. You do rock! :thumbup

I never put 2 and 2 together and figured out why the 4GB+ USB Keys wouldn't boot into DOS 7.1 until I read this. If 1 and 2GB Keys end up going the way of the Altair, do you suppose there could be a way to fix this, at least for DOS 7.1?

No. That's not the case. I do have three 8 GiB, one 16 GiB and one 32 GiB pendrives and one 16 GiB plus two 32 GiB SDHC cards, and all of them boot perfectly with DOS 7.10 our DOS 8.0. One of the 8 GiB pendrives is an OCZ ATV Turbo, while all the others are Corsair Voyager (normal or GT) and the SDHC cards are SanDisk Extreme III (class 6 or 10), in case that may be relevant.

Link to comment
Share on other sites

I have released my KERNEL32 2GiB Bug Fix Patch. This Patch supercedes the COPY2GB Patch as it supports all three Seek Modes unlike COPY2GB that supports only Seek from Beginning of File.

It is available free from my website rloew1.no-ip.com in the Prerelease and Beta Section.

Hi rloew...

I think there may be a bug in your KERNEL32 2GiB Bug Fix Patch...

Yesterday, I updated the old COPY2GB KERNEL32.DLL to your version...

When I went to use VideoReDo Plus (a video editing app), it kept crashing with an error involving msvcr80.dll...

Using Dependency Walker, it showed that msvcr80.dll is linked to KERNEL32.DLL...

I switched back to the old COPY2GB KERNEL32.DLL and after a reboot, VideoReDo Plus ran fine...

Just thought I'd let you know... :)

Try Downloading it and testing it again. I have updated it.

If it still doesn't work please post some more details on the errors.

Link to comment
Share on other sites

[except for 98KRNLUP, since my DLL's seem newer than this).

And, what version do you have? Can you share it with us?

On closer inspection ... the dates are newer, but the files are the same - except for 'advpack.dll' which is 6.00.2900.2180 (rather than 5.00.2013.1301).

This is interesting, I never really thought about it. I used to maintain USB keys that booted and allowed for BIOS updates and using Ghost clients. Originally we used the Win98 bootfiles that is in every version of Windows format tool since 98, but had to go to DOS 7.1 in order for certain NDIS drivers to load properly. We didn't run into any problems with creating these keys until we tried 4GB and 8GB keys. All the normal ones were 1GB keys and they always worked fine. Now it seems that USB Keys under 4GB are becoming a rarity.

I never put 2 and 2 together and figured out why the 4GB+ USB Keys wouldn't boot into DOS 7.1 until I read this. If 1 and 2GB Keys end up going the way of the Altair, do you suppose there could be a way to fix this, at least for DOS 7.1?

No, there's no problem using the Panasonic + Various (eg. Adaptec) combination drivers for DOS, with USB drive partitions up to 64G. The issue here relates to individual files in the 2G-4G size range. BTW as you no doubt know, Ghost will split its image files so they don't exceed 2G [edit: I got that wrong, the split is just under 4G; I think Ghost works at a lower level and hence avoids this 2G bug].

The underlying DLL is the same. The Author of COPY2GB bumped up the Version Number.

Cool. Thanks for the clarification and thanks for the patch, Mr. Loew.

Both LLXX and the anonymous patcher have produced patches derived from kernel32.dll v. 4.10.0.2225, just as RLoew did now.

Sigh! I miss her.

Joe.

Edited by jds
Link to comment
Share on other sites

Try Downloading it and testing it again. I have updated it.

If it still doesn't work please post some more details on the errors.

Sorry rloew... I'm still experiencing the same crash :(.

See the attached file for a basic picture of the crash message and a Dr. Watson crash log...

kerncrash.png

Try this experimental file.

Link to comment
Share on other sites

Guest wsxedcrfv

> While not mandatory, I usually add the Unofficial Win 9x Stack Corruption (98KRNLUP.EXE)

> which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

Just a quick question. What's the source of 98KRNLUP.exe (Krnl386.exe V .2000) ?

Microsoft?

Link to comment
Share on other sites

> While not mandatory, I usually add the Unofficial Win 9x Stack Corruption (98KRNLUP.EXE)

> which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

Just a quick question. What's the source of 98KRNLUP.exe (Krnl386.exe V .2000) ?

Microsoft?

This is the text file that pops up whenever one installs 98KRNLUP.EXE:
Unofficial Windows 98/98 SP1/98 SE KRNL386.EXE 4.10.2000 Fix

EXTREMELY IMPORTANT:

You MUST REBOOT at END of INSTALL to complete properly!

Do NOT install MORE THAN ONCE WITHOUT REBOOTING AFTER FIRST INSTALL!

Everything here applies only to English editions.

This fix/update is cumulative. This means it includes ALL BUG fixes from all previous official + unofficial patches/(hot)fixes/updates. Do NOT replace with ANY other older file version(s) UNLESS having problems with current file version(s).

NOTE:

Provided 'as is', without any warranties, expressed or implied.

Use at your own risk!

INSTALL:

This Fix installs KRNL386.EXE 4.10.2000 into %windir%\SYSTEM [%windir% = usually C:\WINDOWS].

MORE INFO:

KRNL386.EXE 4.10.2000 prevents a rare, but then very often fatal case of stack corruption when certain KERNEL APIs are called.

The only connection to KB891711/Q891711/U891711 is that these 16-bit binaries call at least one of those KERNEL APIs. However, many of the serious problems people reported with KB891711.EXE 4.10.2222 were most likely caused by a buffer overflow condition on the 16-bit stack of KB891711.EXE.

The problems that still occured with KB891711.EXE 4.10.2223 but were much, much less common, were most likely caused by the stack corruption bug in KRNL386.EXE.

This fix was created by an anonymous author, based on the official file from MS.

All I did was to create the IExpress installer, and made up the text file.

HTH

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...