PDF pages are failing to load

[Genki-jp0]

Describe the bug
When you go open pdf files from the internet, they just don't load,
it is worth noting that not all PDF files do not load, infact some do load fine

For example:

failed to load:
https://www.opencompute.org/files/Intels-Journey-w-OpenBMCJamesMihm-OCP18.pdf
https://indico.cern.ch/event/1411901/contributions/6017914/attachments/2919965/5124988/Puneet-ATCF8-TIFR-SR.pdf
https://indico.cern.ch/event/1329196/contributions/5677619/attachments/2755346/4797476/KolkataTier2_JammuAliceIndiaCollaborationMeeting231123.pdf
https://indico.cern.ch/event/1345690/contributions/5665082/attachments/2749029/4784321/7thATCFUpdate.pdf

loaded:
https://indico.cern.ch/event/1386015/contributions/5826817/attachments/2805855/4895984/Kolkata%20Tier2%20Centre-February-2024.pdf
https://indico.cern.ch/event/1322307/contributions/5564713/attachments/2709617/4704804/GridUpdateSeptember2023.pdf
https://indico.cern.ch/event/1322307/contributions/5564715/attachments/2709940/4705389/Puneet-DPM-dCacheMigration.pdf

To Reproduce
Steps to reproduce the behavior:

1. Go to said pdf
2. See error

Expected behavior
PDF Pages loading successfully

Screenshots

Desktop (please complete the following information):

• OS: Windows 7 Ultimate x64 with ESU 2024
• x64

Additional Context
This started happening after updating from a older supermium version to the latest, Version 126.0.6478.249 (Official Build) (64-bit)

[zap369]

Just letting you know that I'm on Supermium 126.0.6478.249 R3-32bit with winXP SP3 and all the PDFs above are loading correctly on my end.

[XakerTwo]

Win 7 SP1 x64 (ESU 2024.09)
Supermium 126.0.6478.249 R3 x64

all PDFs successfully loaded and displayed, even with actively leaking extension and lots of DevTools (also leaking and consuming cpu)

[Genki-jp0]

made a completely new profile in supermium with no extensions at all, experiencing the same issue

[Genki-jp0]

i was running 124.0.6367.245 previously

[Genki-jp0]

went back to 124.0.6367.245, every pdf loads fine now with the exact same settings and profile

[Genki-jp0]

Did some further testing:

124.0.6367.245 - loads all pdfs
124.0.6367.245 R2 - loads all pdfs
126.0.6478.249 - fails to load pdfs
126.0.6478.249 R2 - fails to load pdfs
126.0.6478.249 R3 - fails to load pdfs

All were tested with a completely new User Data folder.

https://www.opencompute.org/files/Intels-Journey-w-OpenBMCJamesMihm-OCP18.pdf

[jimjonesbased69]

Can confirm that on my end, using Windows 7 (x64), some PDF's (such as the ones listed in this issue) are not properly loading.

[Vangelis66]

126.0.6478.249 - fails to load pdfs
126.0.6478.249 R2 - fails to load pdfs
126.0.6478.249 R3 - fails to load pdfs
(...)
https://www.opencompute.org/files/Intels-Journey-w-OpenBMCJamesMihm-OCP18.pdf

Windows Vista SP2 32-bit 3GB RAM
Sm-126-r3_x86 (DWrite.dll working as intended)

No problem here 😄 :

[Genki-jp0]

126.0.6478.249 Prerelease has the exact same issue as all the releases after it, the only difference is that a memory error shows up in the prerelease with the PDF failing to load.
Tested with a fresh User Data folder with default settings, no extensions

[win32ss]

This is a DirectWrite issue. I'm going to make some changes to DirectWrite's internal exception handling to catch DirectWrite-specific errors better, as they are difficult to catch in the auxiliary processes.

But I also noticed that the crash is caused by an attempt to access a null pointer... which was set to 0 by the caller! This is deep into pdfium.

Or maybe not. But only one iteration after the patch was made, it stopped crashing on the particular PDF regardless of the presence of the patch, which seemed to have no effect. Although the root of the issue is that there is an issue with the "fallback" fonts used by pdfium.

UPDATE: this newer iteration of the crash has also been reproduced with other renderers.

[win32ss]

The fallback font used by the PDF font renderer is Arial. If it's changed to Segoe UI the crashes disappear, but I will probably change to Times New Roman or Tahoma to maintain XP compatibility.

Arial Unicode MS, the "Universal Default Font Name" in pdfium, also seems to work.

[Vangelis66]

... IIUC, changes in pdfium between Sm-v124 and 126 are believed to be "the trigger" of this bug; what I don't get is how this bug ONLY affects specific setups (and PDF files); i.e., we have XP SP3 32-bit, Vista SP2 32-bit and Win7 SP1 64-bit (with Sm_x64) where the bug doesn't manifest itself, at the same time Win7 SP1 64-bit (with Sm_x64) where the bug is present... A mystery for the uninitiated such as I 😄 ...

[XakerTwo]

can i assume a specific Windows locale(language)? if so - probably it's somehow related cuz for certain locales Windows has uniq font substitutions, see C:\Windows\inf\fontsetup.inf for some info (it's not so easy to read, but it has comments)

for me display language and non-unicode locale is en-US, but non-unicode locale not affect font substitution(if i'm correct) and for the moment i have no other languages installed

btw - does renaming DWrite.dll to something like _DWrite.dll solve the issue? if so it can be used as temporary workaround

[Genki-jp0]

For me, it is also en-US for both display and non-unicode, im running w7 SP1 x64 with ESU 2024.09 (7601.win7sp1_ldr_escrow.240814-1814).

[Genki-jp0]

Renaming DWrite.dll to anything or removing it does not solve the issue.

[XakerTwo]

iso MD5 is B86A374B412917C704F7AB86059B7D22?
if so - put this in google site:archive.org C9F7ECB768ACB82DAACF5030E14B271E, use VM to check the issue

UPD: Win XP SP2 x64; Supermium 126.0.6478.249 R3 x64 - no issues

[win32ss]

Looking at the first linked PDF in this issue, the text on the second slide is affected, as it uses the selected fallback font.

There was an iteration of the bug that triggered exceptions in DirectWrite, but the DirectWrite issue was later fixed (it was linked to the issue with Latin characters in Chinese fonts), and the issues persist even with system DirectWrite and GDI.

[XakerTwo]

@win32ss

first pdf from "failed to load" section is loaded and displayed as it was before but next three pdf now has issue

126.0.6478.254 R4 x64 @ Win7 SP1 x64

126.0.6478.254 R4 x64 @ WinXP SP2 x64 (VMWare) - no issue
126.0.6478.254 R4 x64 @ Win7 SP1 x64 (VMWare, clean, ESU) - no issue ... will investigate

[XakerTwo]

wth? what is going here - it is back to normal behaviour without obvious reason in the same session

what was made

• browser was closed and started few times with --user-data-dir= and --enable-logging --v=10 (yes 200MB logs here, issue still presented)
• parallelly the same actions was performing on VMWare to get logs from working instance and compare them
• browser was started again in normal mode (issue still here)
• installed Debuggers from WDDK to look into dmp, then start WinDbg, looking over dump and closing it (i didn't find anything useful for myself, all this time i not re-test issue)
• then i open pdf one more time - issue still here, but i start receiving instruction @ 0x________ referenced memory @ 0x00000028 just before crash-face (--disable-crashpad, i forgot about it)
• ProcMon was configured and test capture was made, then general capture started
• target pdf was opened but this time it loaded and displayed correctly
• test of other pdfs - now they also ok

browser restarted but PDFs still opening...

restart on the way, but anyway i'm not satisfied with random floating fix i need to know why - any idea, @win32ss ? i can send dumps(8 pcs) and logs(cutted to ~10MB), but logs is useless - they has no any related errors

upd: yep reload does the trick and issue came back ... with error message

in the same time R3 has no any issues

damn it again self-recovered, now after spooler service was started(to test another issue with R3) - how?!

... totaly magic - single boot, single browser session - it show error, then show pdf, then again error ...

[XakerTwo]

okay i find the reason of issue, in short - it's due to fallbacking to Arial MS Unicode, so the fix actually reintroduce this issue for me
but actually not the font should be fixed but the way it accessing

@win32ss, probably you will be interested in this

long

first, i got this from ProcMon

then i looked at what happens when browser' html-renderer and other software accessing the font

in short - no one software ever attempt to access font files via IRP_MJ_CREATE, most of software did it via FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION.
but Paint.NET did it in more interesting manner - through svchost that serves Windows Font Cache service(some guesses about font cache comes to my mind)

then i create simple PDF with only text "ⒶRIAL UNICODE MS 뱮" and looked at what would happen now - initially i didn't see any requests to ArialUni. Further more, broken files again works and magic now turns into cache(that was populated on creation of the test PDF, a bit later why)

But why those pdf works on VMWare without any caches? I started VMWare again, run ProcMon and saw that (both are captures of R4)

where ArialUni and why regular Arial? I open Fonts folder and did not find unicode version...
Cuz it's vanilla system (mostly), i would prefer not to break Fonts folder to regular(permission etc), so i launch Char map and notice that Arial Narrow, that also accessed on host system, with Arial Unicode MS simply not in the list.

And puzzle done - i remember that Narrow version shipped with Adobe or Office, both present on the host, but not on the guest OS.
And after installing unicode font(and only, it was grabbed from the Fonts folder on the Host) to the guest and rebooting it, same behaviour finally reproduced on guest - crash-face. However, after opening crafted PDF(it opens), fallbacking still crashing... And that was damned font embedding, core feature of pdf btw. (that's why i said cache was populated on creation and not on viewing)

i find some tool that can strip off embedded fonts ... and broke pdf for Reader XI, but looks like font reference was created so i simply drop pdf to browser(Host), saw crash-face and this in the ProcMon

one more attempt in R3(failed) and seems that only first two attempts is loading of the font reference(and in pdf text splitted to two elements), last two is fallbacking.

so i have two guesses about fix fail (but R3 even without fix also show crash-face with stripped off fonts):

• some legacy code in somewhere, that somehow wrapped, but your probably not
• accessing different family is not what expected (both, uni and narrow, are in different family)

and one guess about main issue - not the fallback font should be changed, but how it's accessed. Can you try this way?
For example, FF able to open file, although it not obey the references at all and immediately replace them with most suited fallbacks. And FF also accessing fonts via FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION.

but my guess has one inconsistency - why regular Arial, accessed in the same way, mostly works? does IRP_MJ_CREATE used to check file existence? then why even R3 failed on stripped fonts? content are fine and FF display it

UPD:
oh shit i forgot about 124 R2 that was noted as last working - surprise (not)

while true unicode chars not displays, pdf correctly loaded and displayed, and all fallbacks accessed fonts via FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION. Unfortunately, i lost the first capture and this one is second, so highlighted part is guessed as fallbacking (cache can be engaged), but on first there also was some buffer overflows, like with Paint.NET via svchost

[win32ss]

On my testing system, Arial failed most of the time while Arial Unicode MS worked almost all the time.

In any event, the issue is caused by an attempt to access a non-existent font face object. And the object doesn't exist because of a failed call to gdi32!GetFontData to obtain the sizes of the main and TTCF font tables. SetLastError is only used in some of this function's failure cases but not all. The handle was just created in a successful CreateFontA call.

So I am going to have three fallback fonts instead of one: Arial, Arial Unicode MS and Tahoma. The latter two will only be loaded if the font before them fails. Better this than trying to deal with a possible win32k bug introduced in 2020 or later Windows 7 updates (I believe this issue has been reported before Supermium 126)...

[honx4amiga]

is official supermium 126.0.6478.254 R4 a different version than supermium portable 126.0.6478.254 R4 (https://portableapps.com/apps/internet/supermium-portable)? because according to release notes for official supermium (https://github.com/win32ss/supermium/releases/tag/v126-r4) that pdf bug should be fixed. i'm using supermium portable 126.0.6478.254 R4 and i have problems displaying pdf.

here three examples of pdf files which don't work in supermium portable 126.0.6478.254 R4:

https://www.ris.bka.gv.at/Dokumente/Vfgh/JFT_20241002_24G00120_00/JFT_20241002_24G00120_00.pdf

https://www.dbs.ifi.lmu.de/Lehre/Info1/WS0607/skript/info1_01.pdf

https://www.hs-osnabrueck.de/fileadmin/HSOS/Homepages/Personalhomepages/Personalhomepages-IuI/Westerkamp/Grundlagen_der_Programmierung_Skript_FH_Osnabrueck.pdf

[XakerTwo]

@win32ss , did i understand you correct, that ACCESS_DENIED of IRP_MJ_CREATE is just "induced" error? ^{_{or did you not read the long spoiler?}}

anyway if talk about crutching - is it possible, instead of guessing a font, that may or may not contains required char or whatever, create and force to use an in-memory dummy object, that will displayed as crossed square of size M of Arial(generic replacer in other words)?
if i'm correct, instead of vector, glyph can be a bitmap, so, combining with in-memory, you can try to generate a bitmap with actual hex-code of character just to let user know what char it is, but it's optionally.
if in-memory is hard, maybe a font in supermium subfolder(without installation to Windows) where all possible glyphs are generic replacer or hex-code? I think such kind of fonts should exists and can be used instead of fallbacking to one of probably installed, probably suitable font

Anyway, main goal of this crutch is to create a fallback that is guaranteed to contains the minimum required info for any char.
_{Personally i would prefer in-memory generic replacer, so one read-only object, no IO, no any other issue, should be relatively fast and well felxible}

[win32ss]

is official supermium 126.0.6478.254 R4 a different version than supermium portable 126.0.6478.254 R4 >>(https://portableapps.com/apps/internet/supermium-portable)? because according to release notes for official supermium (https://github.com/win32ss/supermium/releases/tag/v126-r4) that pdf bug should be fixed. i'm using supermium portable 126.0.6478.254 R4 and i have problems displaying pdf.

The bug was originally considered to be fixed, as the configurations used to test for the original bug were fixed at that point. But it wasn't known that it would cause issues on other systems.

@win32ss , did i understand you correct, that ACCESS_DENIED of IRP_MJ_CREATE is just "induced" error?

Yes. The IRP requests are not being made by Supermium directly. It's possible Firefox handles them through DirectWrite instead of GDI APIs, which may entail a very different method of accessing the fonts and their tables.

But I don't think most users would understand the use of a fallback with hex values instead of the actual character.

[XakerTwo]

yep, and if someone needed these codes - there a bunch of tools (online/offline), so as noted before - optional

btw i have not test it, but found atleast one font with such a purpose Adobe Blank 2 (there also link to just Adobe Blank). Both are dated not so far of the XP EOL so there is a chance that they will work correctly.

Other system that is mostly vanila with only installed Arial Unicode MS ... can i ask about the source of your Arial Unicode MS? mine is most likely Office 2010, and font version is 1.01