Why will using any help function in my 64-bits executable kill this executable by an exception and simply execute its duty in an exactly the same 32-bits executable?

Question

In or just before 2020 I detected this problem, described it and asked for help. Even some people recognized it. But no solution was offered and even the future was referenced. Now I have finished developing my project there will remain this ashtonishing difference between the 32 and 64-bits release versions: only the 32-bits executable will show any help from this same chm-file because the 64-bits executable will simply not show anything but even be killed all together by an exception. So far I didn't experience any other striking difference between both versions.

I developed over the years both versions using Visual Studio[Community]. All htlm-files were created/compiled by using the Microsoft HTML Help Workshop generating a flawlessly running chm-file with me supposing applicable to both 32 and 64-bits executables. I know the chm-files are 32-bits generated in the time the HTML Help Workshop was developed no 64-bits being available. The operating system Windows should be able to manage these differences. The exception took place not within my 64-bits executable but somwhere within Windows after the executable's call of HtmlHelp(). So I expected in both calls exactly the same but I remain surprised by the 64-bits executable's deviating behaviour. Can anybody help me? Looking around I am used to detect chm-files used to function as a help tool both for 32 and 64-bits executables. What might I be doing wrong many others are doing correctly?

I inserted my call of HtmlHelp() expecting this call applicable to both 32 and 64-bits versions. And everything written in C++.

Answer 1

@TonEpskamp-0986 I took an existing .chm file (Microsoft Office Developer Documentation) and opened it with HtmlHelp() from a 32-bit and 64-bit minimal Windows Desktop application. The function completed successfully and opened the help file in all cases.

The documentation for the HtmlHelp function contains a caution that the executable must have a stack size greater than 100K. I changed the default stack size to 64K for my test application and then calling the function resulted in crashes for both 32-bit and 64-bit code.

I wonder if your 64-bit executable has been linked with an insufficient stack size (the default is 1 MB).

For a C++ project the project property page where the stack size can be set is shown below -

You can check the stack setting for your executable by opening a Visual Studio Developer Command prompt and using the command --

dumpbin /headers YourProgram.exe

The following demonstrates what dumpbin shows as the stack sizes for the default settings -

The figures are in hex -- the stack reserve is 1 MB and the commit is 4K.

Answer 2

In cases where persistent, inexplicable anomalies are experienced in a program it often happens that we are thrown off the track by focusing exclusively on the symptoms. When vigorous analysis of the code fails to reveal the cause in the area suggested or suspected according to the symptoms experienced, it often indicates a need for a thorough analysis of the entire program. The true cause may lie somewhere other than the line which triggers the errant behaviour.

Frequently there are causes such as heap or stack corruption, errant/invalid pointers, buffer or variable overruns or underruns, OBO bugs (Off-By-One), etc. Latent bugs in code may not exhibit any adverse symptoms in one type of build, while surfacing in another build. Examples of this often occur between Debug and Release builds of the same code, builds using different compiler versions, etc.

Often a thorough analysis of the entire program is needed or helpful. This should include the use of static code analyzers. More than one should be employed.

Of course, all builds should be done with the maximum warning level set, and all warnings should be investigated and eliminated wherever possible. Ignore Warnings at your own peril.

Conversion of code from 32-bit to 64-bit can present some pitfalls when the code has some inherent assumptions which aren't valid between those platforms. e.g. - pointer sizes. size_t underlying types, etc.

Common Visual C++ 64-bit Migration Issues

https://learn.microsoft.com/en-us/cpp/build/common-visual-cpp-64-bit-migration-issues?view=msvc-170

Migrating C/C++ from 32-Bit to 64-Bit

https://www.informit.com/articles/article.aspx?p=2339636

"Migrating 32-bit C/C++ code to 64-bit is not a trivial task. There are many issues to consider. This article looks at the areas of numerical limits, data alignment, pointer arithmetic, and array indexing."

Seven Steps of Migrating a Program to a 64-bit System

https://pvs-studio.com/fr/blog/posts/cpp/a0042/

20 issues of porting C++ code to the 64-bit platform

https://hownot2code.wordpress.com/2016/08/29/20-issues-of-porting-c-code-to-the-64-bit-platform/

• Wayne

Answer 3

I asked a question about both "x64" and "x86" each other excluding #defines but Microsoft does still te be angry with me because I posted it in vain. So I will try again! That would be a wonder!