Latest release crashes with a HTML 4 input file

[x-y-n-i-x]

The latest release (GUI) for Windows 10 crashes with HTML 4 input files, with settings that should work with the previous release.

Document type: Web Page
Input File: attached (HTML file, in attatched ZIP file)
html4.zip
Output Path: X:\Y:\test.pdf (in same directory as the input file)
Page Size: A4
Headers/footers: all blank
Body typeface: Helvetica
Options: Disble Embed fonts
Generate
A message "loading file" appears, with a yellow background. Next the crash, I've tried it with several input files..

For now I'll downgrade to the previous release for Windows, since this issue is new for me. A reboot may solve it, because the latest release used to work too.

[michaelrsweet]

Hmm, I just tried your HTML file on macOS and had no issues. Are you using the MSI installer file from Github or did you compile from source?

[x-y-n-i-x]

Hmm, I just tried your HTML file on macOS and had no issues. Are you using the MSI installer file from Github or did you compile from source? After a reboot, I've tried it with a different HTML file. Same problem. Windows 10, MSI-installer. Earlier I have produced PDF files using this version, so it worked at least once for me. After the reboot I was able to read the message, which you wouldn't notice normally. "Loading R:\AM-disk\inputfile.html..." I can see that message for a short while (yellow background), and then the GUI exits without any dialog or output file. I have no specific reason why it started to fail for me, and still does. I can delete and regenerate such a HTML file, It's not the same (not all options in use), but I can send a PDF-file to STDOUT by using the CLI version. But ... After a few second, Windows produces a sound. Presumably an ERROR.WAV. htmldoc.exe --format pdf13 --webpage r:\am-disk\inputfile.html If I redirect this output to a PDF file, the PDF file seems to be allright. But then there's still the modern version of a (Windows?) BEEP using the CLI version, and the fine GUI doesn't produce output and just "crashes"/exits without any dialog. As an OS/2 survivor I'm not that familiar with Windows, but the modern BEEP may indicate some OS/API-related error. The delay is about the same. The period of time between "Generate" and the crash of the GUI, and the period of time between seeing the end of the STDOUT PDF file and hearing the BEEP. One second, roughly. All tests were performed with the latest version, and the CLI version is capable to produce proper output. But not silently. By the way, is it possible to document what latest releases there were for 32-bit Windows versions? I've found the answer by trying many versions, but I may have overlooked existing documention.

[x-y-n-i-x]

I have attached a MP3 file. If that works, then you'll here me destroying the ENTER key, and after a while the "modern BEEP" caused by HTMLDOC.EXE (CLI version). No beep: htmldoc.exe --webpage index.html Beep (command used during the recording): htmldoc.exe --webpage --format pdf11 index.html In all cases output to STDOUT and STDERR looks normal, with an expected speed of execution. The GUI version crashes silently, so obviously I haven't recorded that. The system should be up-to-date, including optional updates of Windows 10 Pro, and Microsoft's default virusscanner hasn't removed anything lately. An update of Microsoft could be the cause, since the GUI used to work. I assume the modern BEEP of the CLI version is equal to the crash of the GUI version, but without any output (other than the message "Loading index.html...") and without the beep. If you don't receive the audio file, then it's a single beep. Shorter than a "Windows 10 fatal error sound", AFAICT. Nonetheless it looks/sounds like Windows has a problem when --format pdfXX is used (I've tried 11 and 13). I hope you do receive the MP3 file this way, to get further than some user reporting hearing a HTMLDOC-sound which nobody else can hear nor reproduce...

[x-y-n-i-x]

Parts of Windows error logs, using the GUI version, in Dutch. The recommended admin's "sfc /scannow" in case of 0xc0000005 didn't help, and I may ba possible that some standard Windows update triggered or exposed a problem: Bron: Application Error Beschrijving: Naam van toepassing met fout: ghtmldoc.exe, versie: 0.0.0.0, tijdstempel: 0x67571387 Naam van module met fout: ucrtbase.dll, versie: 10.0.19041.3636, tijdstempel: 0x81cf5d89 Uitzonderingscode: 0xc0000005 Foutmarge: 0x0000000000025f31 Pad naar toepassing met fout: C:\Program Files\HTMLDOC\ghtmldoc.exe Pad naar module met fout: C:\Windows\System32\ucrtbase.dll Handtekening van probleem: P1: ghtmldoc.exe P2: 0.0.0.0 P3: 67571387 P4: ucrtbase.dll P5: 10.0.19041.3636 P6: 81cf5d89 P7: c0000005 P8: 0000000000025f31 P9: P10:

[x-y-n-i-x]

A generic suggestion (in case of dynamic linking?), just quoted by me (https://superuser.com/questions/1397010/application-crash-due-to-ucrtbase-dll), and not sure if it'll help: "I would start, if you are the author of the program, by updating your solution to point to the correct version of ucrtbase.dll".

[michaelrsweet]

The MSI file should be triggering the installation of the Microsoft C Runtime DLL. This isn't something I can (legally) bundle myself, but I will see what is going wrong. (I build on Windows 11 these days because Windows 10 is almost EOL).

[x-y-n-i-x]

The MSI file should be triggering the installation of the Microsoft C Runtime DLL. This isn't something I can (legally) bundle myself, but I will see what is going wrong. (I build on Windows 11 these days because Windows 10 is almost EOL). I do have several runtimes installed, including Visual Studio's. And I do have several copies of that file UCRTBASE.DLL. I'll try to re-install the latest MSI file anyway, but IIRC it didn;t trigger the download of anything else. So that may already be there. superuser.com did mention several possible causes. One recommendation is installing a Windows 10 SDK. (Don't ask me why, but) I've got a Windows 11 SDK installed. I'll first try to excplicitly install a Windows 10 SDK (for Windows 10 hardware), before trying to re-install the MSI file. I'll let you know if any of those steps helped. Otherwise I won't. Please note I'm not a Windows programmer nor some Windows veteran, so don't overrate me nor my skills. I'm just using Windows 10 because "I have to", and upgrades to 11 are denied (by unavoidable Microsoft requirements). To do: - test with Win 10 SDK (in addition to Win 11's) - re-install MSI - lucky? I'll let you know.

[x-y-n-i-x]

The MSI file should be triggering the installation of the Microsoft C Runtime DLL. Probably already installed indeed. Installing the Windows 10 SDK didn't help, nor (removing and) re-installing the latest MSI file. No sign of any runtime DLL/package being installed, so it was probably already installed always (by something else). FWIW, the details of the DLL file in the System32-directory of the Windows 10 error log file, albeit I've already mentioned a version number: 04-12-2023 03:46 1.046.080 ucrtbase.dll FWIW/2, the whole issue is new to me. There are no other errors in the Windows 10 error logs, and it used to work. It still does, in a way, if I'ld redirect STDOUT, forget about the fine GUI, and don't mind a beep nor logged errors. Avé, André