Visual Patch crash in NT4 - FIXED

[vppas]

I use the evaluation version 2.0.3.1. I create a "patch" in XP and the patch works fine in XP. When I run the same "patch" in NT4 SP6 doesn't work, appears a Dr Watson window and in the DrWatson's log file the fault are in the function GetDiskFreeSpaceW.
What's wrong?

Thanks
PAS

[ineb]

Hi,
tried out my patch on Win NT too. Same error as you described! But i choose Visual Patch because Indigo Rose says that it supports all windows versions!

[Lorne]

I haven't been able to replicate this here yet. Would it be possible to send us the project file?

Are you using UNC paths?

At what point does the error occur?

Do you have logging enabled? (In the Project Settings, enable the "Create log file" option and set Include action details to "Extended Errors.") What does the error log say?

Does the error still occur if you enable "Force Install" on all files? (To bypass the binary patching as a test.)

[ineb]

I'm using Setup Factory 7.0.4.0 and Visual Patch 2.0.2.0. Setups works fine on all systems. I tried out the patch on WinXP SP1 and Windows NT SP 6, running both systems on Virtual PC.

The error occured when patching the first file. Dr. Watson pops up with the message: access violation vpatch.exe (0xc0000005), adress: 0x77f170bf.
The last entry from the log file is: "Run project event: On Pre Patch".
In the advanced settings i turned on file rollback support.

I build a smaller project and try out a patch with "force install" on all files.

[ineb]

Now I've tested a patch with "force install" on all files and evereything was ok. But that is not the patch i wanted to build for my software because of the large patch size.

[vppas]

I haven't been able to replicate this here yet. Would it be possible to send us the project file?

Are you using UNC paths?

At what point does the error occur?

Do you have logging enabled? (In the Project Settings, enable the "Create log file" option and set Include action details to "Extended Errors.") What does the error log say?

Does the error still occur if you enable "Force Install" on all files? (To bypass the binary patching as a test.)

In attachment are the project, project's log, patch's log and DrWatson's log.
When the patch stops are files _vp1.tmp (equal to key file) and diff_000001.dif in destination folder and a folder BACKUP with a backup of key file.

I'm not using UNC paths.

When I enable "Force Install" for all files the patch works, if I enable "Force Install" only for the key file, the key file "works" but stops in next file.

[Lorne]

Thanks guys, those are good clues. Looks like there may be an undocumentend incompatibility with one of the Windows API calls in a very specific sub-version of NT.

The patching engine uses different file I/O methods than what is used for the whole-file part of the runtime, which is why I asked you to test it with "force install" turned on. That essentially circumvents the sophisticated high-perfomance I/O stuff in the patching engine.

If my hunch is correct, the problem isn't actually in the high-performance I/O routines themselves; it's earlier on in the part that tries to determine the correct (safest) parameters to use for that specific system. Which is kinda ironic.

Thanks again for responding so quickly, guys. I'll let you know more as I get to the bottom of this.

[Lorne]

Ref: 12624

[Lorne]

I was able to reproduce the crash on one of our test systems...the old Dr. Watson error report contained a short assembler burp from around the instruction pointer, revealing the GetDiskFreeSpace function's innards, so it was pretty easy to spot the problem.

My hunch was correct; the problem was an undocumented bug in the implementation of the GetDiskFreeSpace function on NT4 SP6. That specific version of the GetDiskFreeSpace function (which has been around since Windows 95) handles its parameters differently than all of the others.

A quick search on google didn't turn up anything about it, which isn't that surprising. GetDiskFreeSpace doesn't support drives larger than 2 GB, so these days most things that actually want to get the free space on a drive need to use the newer GetDiskFreeSpaceEx function. In our case, however, I didn't care about the amount of free space; I just wanted to get the actual sector size of the target device, so I could properly size and align the memory buffers for high-performance synchronized unbuffered I/O.

However, the newer GetDiskFreeSpaceEx function doesn't have the ability to get the sector size...for some reason that part was left out. Luckily, the old GetDiskFreeSpace function still does that one job fine. (Which is a lesser-known fact, actually, since the documentation for GetDiskFreeSpace makes it sound like it doesn't work at all on drives larger than 2 GB.)

The relevant parameters of the GetDiskFreeSpace function are a bunch of out pointers (pointers to memory locations where you want the function to store the results). On every other version of Windows that I've tested, the GetDiskFreeSpace function lets you pass NULL for the parameters you don't care about -- in which case it just won't return the corresponding result.

On NT4 SP6, though, the function blindly tries to fill all of the parameters, even if they point to NULL.

The fix for this bug was incredibly simple. I just had to change this:

GetDiskFreeSpace(m_strDrive, NULL, &bytesPerSector, NULL, NULL);

...to this:

DWORD dwDummy;
GetDiskFreeSpace(m_strDrive, &dwDummy, &bytesPerSector, &dwDummy, &dwDummy);

Since getting that other information from the file system could potentially slow the query down a bit, and this is intended for high-performance use, I ran a series of speed tests to be sure. On the systems I tested it on, the performance difference was negligible.

In any case, this bug has been fixed, and I'll recommend that we put out an update as soon as possible.

[Darryl]

Hi Guys,

We put out an update today (v2.0.4.0), so this issue should be fixed now.

[ineb]

Hi IngigoRose Team,

thank you for fixing this bug so fast!