Error during build: Access violation at address 7570DC4A in module 'msvcrt.dll'. Read of address 0A1B0000

[anja_laenge]

Hi,

we need to change a singleFile.EXE build to singleFile.MSI in X14

singleFile.EXE always worked fine and still does.

First build attempt with output to default (project folder) gave Error during build: Access violation at address 7570DC4A in module 'msvcrt.dll'. Read of address 0A1B0000

repairing Microsoft Visual C++ 2015-2022 Redistributable (x64) and Microsoft Visual C++ 2015-2022 Redistributable (x86) and building to custom Folder D:\ gave the same error but with a different address.

Building to output folder D:\ with InstallAware started as Admin also gave the error, again with another address.

Please advise.

Kind regards
Anja

[JohnGaver]

Not sure where that's coming from.

We're not a Visual Studio application, so we don't link in their runtime msvcrt.dll at all.

Can you please provide step by step instructions on exactly what you are doing, so I may strive to provide you with better guidance?

Also, could you please try with the latest version of InstallAware X18 to see if this replicates this issue?

I'm afraid we wouldn't be able to test this on InstallAware X14 at all.

[anja_laenge]

Hi John,

the current project is configured to build its output to the default folder
- root
-- .mpr
-- Release
--- Single
--- Uncompressed

this was always done with output in .exe format.

Now, in the project settings page i switxched to produce .msi and kept the rest identical.
-> Build -> Access violation

I repaired both C++ Redistributables and choose the custom output folder d:\; so the strucure would be

D:\
- Release
-- Single
-- Uncompressed

-> Build -> Access violation

Restart X14 as Admin

-> Build -> Access violation

I just tried another computer with a fresh X14 installation and the problem is the same!

Last lines of the log window:
Compressing install: OFFLINE\CB93C47A\46A95270\_._ (98%)
Compressed setup files
Prepared SFX data
Created SFX file
Cleaned up
Producing MSI output...
Error during build: Access violation at address 775BAC8A in module 'msvcrt.dll'. Read of address 0A715000

this seems to be the very last step. In the \Release\Single folder there are two files: the setup.exe with 2,9 GB and the setup.msi with 15 KB

Since the payload is approximately 2.9 GB, Does InstallAware X14 support a single MSI with embedded content larger than 2 GB? We suspect this may be hitting a technical limitation of Windows Installer/CAB (e.g., a ~2 GB cabinet size limit), so please confirm what the supported maximum is and what the recommended workaround is (multiple/external CABs, etc.).

We do use X14, we do not have X18.

Kind regards
Anja

[JohnGaver]

Currently, the only supported version of InstallAware is InstallAware X18.

We can only help you with guidance as InstallAware employees only if you're running our the latest version.

That said, it sounds like you would certainly be running into the 2 GB MSI file limit.

What's crashing are the MSI APIs themselves - not our code, but Microsoft's code.

Again, we don't have any dependencies on MSVC runtimes - Microsoft does.

However, as you have already surmised, the issue isn't related to an MSVC runtime dependency at all.

You're simply hitting the 2 GB MSI file limit, which Microsoft code is apparently not checking for - instead, summarily crashing.

Again, with that said you're hardly ever stuck with InstallAware.

I'd switch to a Web Build, with the main payload (Offline Web Media Blocks) less than 2 GB in compressed size.

The rest of data can be read successfully from 7ZIP files - the online Web Media Blocks - to be found alongside your MSI file.

These will work in all scenarios, including Group Policy Distribution.

The path where those 7ZIP files would be located at runtime is going to be

$GPOPATH$

for those curious about it.

Not that you'd need to manually extract any of those 7ZIP files at all, of course - InstallAware will take care of it for you automatically, as long as the 7ZIP files are located inside the same folder as your setup.msi database at deployment time.