[TC 11.00rc1] Crash when using Help > Index > Keyword

[ghisler(Author)]

The version number of hhctrl.ocx is 10.0.19041.746, dated 2021-05-21, and the offset of the error was 0003d082.
So the version and error address are different.

I tried deleting the file hh.dat, but this didn't make the error occur again, even after a reboot. hh.dat was just recreated.

My Samsung laptop with Windows 10 also has Windows 10 22H2, but has version 10.0.22621.1 of hhctrl.ocx.

[white]

My Samsung laptop with Windows 10 also has Windows 10 22H2, but has version 10.0.22621.1 of hhctrl.ocx.

Does this laptop and you brother's pc have the same version of Edge installed?
And do the versions of mshtml.dll differ?

[ghisler(Author)]

Yes, both had Edge 114.0.1823.82 at the time of the error, and mshtml.dll version 11.0.19041.3155 dated 2023-07-12.

But when I opened the info page in Edge, it immediately started updating. It has now changed to Edge 114.0.1823.86, but the version of mshtml.dll has not changed.

[white]

And what are the Microsoft .NET Framework versions?

[ghisler(Author)]

Which .NET version? You can have multiple .NET versions installed in parallel.

[white]

Which .NET version? You can have multiple .NET versions installed in parallel.

I know, perhaps the latest .NET framework versions. I'm just guessing which components might be of influence on which updates are installed by Microsoft.

[brahman]

Here is a link to the help executables as 2AnthonyD suggested:

https://www.mediafire.com/file/pij2ptty9idf5c0/HelpSystemWin11-21H2.7z/file

[brahman]

Here are the procmon log files for the crash:

https://www.mediafire.com/file/rsy2ljkblmptmpx/ProcMonLogFiles.7z/file

I think sections from 18:22:44 to 18:22:47 are the most relevant. That's where the crash occured when opening Help with F1 and entering letters.

[AntonyD]

Here are the procmon log files for the crash:

Unfortunately, I will not say that something very useful can be seen in this log (although I had high expectations for this tool)
But one moment definitely draws attention to itself - there is an appeal first of all to the file mshtml.dll !!!
Which is an essential part of installing Internet Explorer! What about this component?
After all, as we know, his support has long been closed. Especially for win11.

P.S. and more important news))
Suddenly after that I was able to find the system where I can reproduce the problem 10/10 times)))
And despite that fact what we have on this machine VS2019 - debugger literally shows nothing when we tried to debug the crashed process...
This windows 11's the "thing" is going to drive us crazy, imho.

[AntonyD]

I was able to find out some wrapper for hh.exe file created by Russian programmer
https://www.manhunter.ru/releases/722_htmlhelp_wrapper_2_2.html
Any of you can translate all text there, but one main part I want to highlight right now:
"...for CHM files, additionally automatically synchronize the list of keywords and the open article, as well as open more than one copy of help for a single application and close the open help by pressing Esc. It is possible to open help files with Unicode names..."
I just tried to use it - and got 0 problems with it.

[ghisler(Author)]

I'm not calling hh.exe, instead I'm loading htmlhelp.ocx via LoadLibrary and then call the function HtmlHelpA.

[AntonyD]

2ghisler(Author)
Mentioned found Wrapper does the same things. PLUS it supports all options of original hh.exe, which in turns ALSO is a simple wrapper for htmlhelp.ocx
So what I actually want to suggest is that you can also provide this htmlhelp.exe file as part of the Total installation.
And the call for help F1 now can be done already EXACTLY through calling this exe and substituting the required option/key to open the required help section.
Taking into account that this Wrapper supports opening and maintaining several CHM files in one session - it will be more convenient for users to open the original help in English, for example, if there is no corresponding section in the localized help file.

We have to agree that Microsoft can and probably will fix some bugs in its hhctrl.ocx file, but it is very likely that it will be done finally in style - we no longer support this subsystem, use third-party tools, and from next version we remove the corresponding files from windows installation. And they actually stopped support since 2008 or so for this component. It's still version 1.4. Sometimes is shows 1.41 - but not more...

[ghisler(Author)]

What's the advantage compared to calling 32-bit hh.exe?

[AntonyD]

translated quote from description from the site of the author of this wrapper:

HtmlHelp Wrapper is a wrapper for opening .CHM files and .HLP files from batch files or applications. This program differs from the usual HtmlHelp utility that comes with Windows in that when you open a help file, it allows you to [do the really working] search for keywords, and for CHM files, additionally automatically synchronize the list of keywords and an open article, as well as open more than one copy of help for a particular application and close the open help by pressing Esc. It is possible to open help files with Unicode names. In addition to its functions and launch options, all standard HtmlHelp utility keys are supported, so you can replace the hh.exe file in the Windows folder with HtmlHelp Wrapper (don't forget about backups).

Of course, if we need a much more useful additional "load" that you could perform by this wrapper - then yes, since it is not there yet - then calling a 32-bit hh.exe is enough. Probably... But I would look ahead. This wrapper has a really working property to load the hhctrl.ocx file from the folder where it is located. The built-in hh.exe is guided in this regard by certain entries in the Windows registry. And if they are there and if they are valid, then everything works fine. But if they are not there, or they are broken... And then we are provided with a lot of problems when opening help files. With this wrapper, we can even start adding our own version of hhctrl.ocx. Just in case the dire consequences of Microsoft disabling support for this help file viewer component in Windows suddenly start to get worse.

[ghisler(Author)]

Unfortunately using such a tool doesn't really help with the original crash issue. I would have to call the 32-bit version of the tool, but the 32-bit subsystem may not even be present (e.g. on some Windows PE builds run from USB), and we can't change pages once the help is up (e.g. when you press F1 in one dialog and later in another, it could not open that page in the existing viewer). So for now we will unfortunately have to live with this help system bug, sorry.