I'm not surprised that you can't reproduce it. I'm having difficulty reproducing it on another PC myself.
However, I have made progress on the problematic PC and have determined that it's an issue with fonts that are installed by another application that are causing the problem.
If I remove the font registry entries on the problematic PC, the HTMLUI control behaves properly. If I put the font registry entries back in, it fails to render. No exceptions are ever generated in the Syncfusion code. See below.
Additionally, if I remove the fonts while the HTMLUI application is running (BTW, I reproduced the bug with the HTMLUI_Explorer sample), new HTMLUI controls that get created still don't work. It only starts working again once the application is closed and started again. This tells me that there must be some kind of static data (some kind of font cache perhaps?) that loads at startup and doesn't get refreshed.
The fonts that cause the problem are the first ones in the list of fonts found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts:
In fact, just deleting the registry values for "3ds (TrueType)", "3ds-Bold (TrueType)", "3ds-BoldItalic (TrueType)", and "3ds-Italic (TrueType)" makes the HTMLUI control work again.
The only odd thing about those fonts is that the extension for the font file is .ttf, (for TrueType) but the fonts are in fact OpenType fonts, which is reported by Windows if you double-click the font file manually to view it. I doubt that this is the problem, but it's weird that these are the only ones that cause the problem and that they're the only ones with the incorrect extension.
Is there any Syncfusion code that loads fonts and could fail for some reason? Maybe the static "font manager" isn't loading any fonts at all because the first one fails. If so, it should continue trying to load the rest of the fonts and ignore the failure of loading a single font.
I tried with older versions of our application that used previous versions of Syncfusion and the problem existed then also. So the problematic code has been around for a while.
We're currently using Essential Studio 220.127.116.11.