32-bit version crashes on startup due to vs 2022 code generation bug

[GitHubRulesOK]

SumatraPDF version

• Version [e.g. 3.5.2, pre-release]
  pre-release 15966
  Describe the bug
  A clear and concise description of what the bug is.
  initially crashed on opening with 2 tabs active retested with no settings and it just crashes !
  To Reproduce
  Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.
no crash the files have oddities but should not trigger a crash
File that reproduces the problem
If this is related to a specific PDF etc. file, please attach the file.

one file is sample used to describe issue with underline thickness the other is much larger and should not present a problem here but was edited twice at source so has incremental xrefs
underline scale 4.pdf
seems to be the offender

However without that file others also fail so probably the URLS
sample-file (with videolink).pdf

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[kjk]

Can't reproduce

[GitHubRulesOK]

sorry should have said 32bit installed as still cant test 64bit yet I have no problems with installed 15963 (so reverted ) but 966 throws me out as soon as open a file ?? I have not rebooted so there could be some conflict somewhere but cant see what.

[kjk]

can you attach crash report (make sure symbols are correct)

[GitHubRulesOK]

Ahh are you saying the symbols had not updated ?

[GitHubRulesOK]

Symbols unpacked before fresh install
sumatrapdfcrash.zip

thought I had deleted settings.txt though I got something wrong a home screen was populated hmmm
any way it crashed on opening

[kjk]

it seems 32-bit build just crashes

[GitHubRulesOK]

As said I have not rebooted and dotted about in this poor example of a Modern PC struggling with Enterprise 10 updates MuPDF got frozen at 1.20 (now we are at 1.24 ish so I managed to cobble VS2017 into building 1.23.1 as 32bit thus that may be "lurking" about. but should not be in memory as inactive.

[kjk]

Looks like mis-compilation. The version built by GitHub bot (VS 2022) crashes but I can't reproduce building locally using VS 2022 Preview doesn't.

The one that crashes:

010DFDD3  push        ebp  
010DFDD4  mov         ebp,esp  
010DFDD6  push        ecx  
010DFDD7  push        ecx  
010DFDD8  push        edi  
010DFDD9  mov         byte ptr ds:[0],0  
010DFDE0  mov         edi,offset g_threadCritSec (01B664ACh)  
010DFDE5  call        ResetTempAllocator (010DE9D7h)  

The one that doesn't crash:

static DWORD WINAPI FileWatcherThread(void*) {
00C02D55  push        ebp  
00C02D56  mov         ebp,esp  
00C02D58  push        ecx  
00C02D59  push        ecx  
00C02D5A  push        edi  
00C02D5B  mov         edi,offset g_threadCritSec (0CB8590h)  

The one that crashes has:

010DFDD9  mov         byte ptr ds:[0],0  

ds is 0 so it tries to store at address 0 which is a crash.

Version of VS on github:

MSBuild version 17.9.5+33de0b227 for .NET Framework

Strange version because latest is 17.9.2 (https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-notes)

[GitHubRulesOK]

Ensured nothing visible in memory that could interfere except defender !
deleted program files exe and dll (not the folder) and deleted appdata local settings.txt
did full "admin for all users install" with search and preview (as per usual) it wrote all 3 files to program files directory (as expected) and started without settings (which it did build fully as 2KB and trailer line.) then as fast as before simply crashed.
sumatrapdfcrash.zip

[kjk]

Per https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md installed VS version is 17.9.34616.47.

Will have to wait until they change it and then re-check if it still mis-compiles.

The OS image was last updated on 20240225.2.0

[kjk]

Could try to use windows-2019 image which has Visual Studio 16.11.34601.136 (https://github.com/actions/runner-images/blob/main/images/windows/Windows2019-Readme.md)

[kjk]

still crashing in latest pre-release even though vs version is updated to 17.9.34714.143

[GitHubRulesOK]

thought so thus not updated yet
so missing all those good enhancements since 15963 :-0

I cant get all of MuPDF Mutool to compile as 1.24 it builds BUT some commands work and others (like newer trim) dont

[GitHubRulesOK]

Interesting status since I was eager to see new interface enhancements I download 32bit daily and as expected it starts with a crash.
HOWEVER if I dont acknowledge it went unstable, it carries on allowing me to select and read files as long as dialog is not closed!

sumatrapdfcrash.zip

[kjk]

I've downgraded GitHub daily builder to earlier vs version. Hopefully it'll fix the next daily build.

[GitHubRulesOK]

Will let you know or will close if it works.

(My issue with MuPDF code is that the std viewer works but my preferred GL variant fails most often over 95% (oddly not always other than seems good without graphic objects and no simple reason) to display with this 32bit graphics system but there is no newer driver to try!

P.S forgot to say the interface before crashing looks way better,
so should address a lot of old issues (except bookmarks :-)

[kjk]

I forgot that building with vs 2019 is no longer supported so have to wait for Microsoft to fix the vs 2022 code generation bug and update the GitHub runners.

[GitHubRulesOK]

@kjk I persevered with 32 bit in VS2019
now as you know I have no idea what I am doing in that IDE so rely on the warnings thus I set all options preferences to use v142 not v143 (which is not available for 2019)
and got some success EXCEPT for one problem that took me a while to track down.
so by blocking the two sections of one commit 04c50ae I have what seems to be a Windows 10 x32 working copy without crash on first UI render?

There are still warnings about heic so perhaps that may need me checking/not using them but as there is no heic enabler on this device (paint cant open them) thats currently not my issue.

Error Problem seemed to be definition of DWMWINDOWATTRIBUTE::DWMWA_CAPTION_COLOR was unacceptable ! and as you can see I tried to remove that but then it kicked back that my edit was worse :-)

[kjk]

If you compile with vs 2022 preview (https://visualstudio.microsoft.com/vs/preview/) it should be fine and require no changes.

It's just that the version of vs 2022 installed on GitHub's build servers is buggy when generating 32-bit code and I have no way of changing the version.

Hopefully eventually they'll fix that and update build server.

[GitHubRulesOK]

Catch '22 Vs 2022 says

The following are not supported:
32-bit and ARM32 operating systems.

So I cant install on 32bit to build 32bit !

[GitHubRulesOK]

HMmmm
ITried the latest version however debug run fails with same WinDynCalls. that were updated for Win11 so I still have to make 2 sets of edits 1 there and Caption.cpp

P.S that fail MSB3073 has popped-up only in most recent few days and 2 daily pre-release runs have failed too so unsure if related.

Severity	Code	Description	Project	File	Line	Suppression State
Error	MSB3073	The command "cd ../out/dbg32\..\.. & go run ./do -gen-docs
:VCEnd" exited with code 9009.	SumatraPDF	C:\Program Files\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets	145	
Error	C2838	'DWMWA_CAPTION_COLOR': illegal qualified name in member declaration	utils	C:\Users\lez\source\repos\sumatrapdf\sumatrapdf-16101\sumatrapdf-master\src\utils\WinDynCalls.cpp	199	
Error	C2065	'DWMWA_CAPTION_COLOR': undeclared identifier	utils	C:\Users\lez\source\repos\sumatrapdf\sumatrapdf-16101\sumatrapdf-master\src\utils\WinDynCalls.cpp	199	

[kjk]

16105 or later should not crash there

[GitHubRulesOK]

@kjk
16105 same 3 errors
I appreciate your attempts to humour an ailing platform but that Win 11 syntax is still not accepted on Win 10 Vs2019+tools v142
is there a simple way to say IF win10 then skip this win 11 code as manually I have to

find src/utils/WinDynCalls.cpp
about line 200

// https://stackoverflow.com/questions/39261826/change-the-color-of-the-title-bar-caption-of-a-win32-application
//REMove for 32bit win 10
//HRESULT SetCaptionColor(HWND hwnd, COLORREF col) {
//    return SetWindowAttribute(hwnd, DWMWINDOWATTRIBUTE::DWMWA_CAPTION_COLOR, &col, sizeof(col));
//}

goto src/Caption.cpp
about line 175

//REMove for 32bit win 10
//    if (gGlobalPrefs->useTabs) {
//        COLORREF col = ThemeControlBackgroundColor();
//        dwm::SetCaptionColor(::GetParent(hwnd), col);
//    }
}

the 3rd issue seems to be I have NO GO as it throws up virus warnings I could not install GO in the past.

[kjk]

Official 32-bit build should not crash anymore so you don't have to compile from sources, just download the latest pre-release binary.

[GitHubRulesOK]

ahh that will be tomorrow mornings daily ?

however now I have got so close, it would be nice to bypass the GO limitation can I simply somehow block that step or is it essential it builds some support ?

[kjk]

It's already out at https://www.sumatrapdfreader.org/prerelease, just make sure its 16105 or later.

Go is unfortunately needed. If you have winget, you can install it with winget install GoLang.Go

[GitHubRulesOK]

Thanks
I will try official however I have downloaded latest gox86 so will see if it runs!
but I prefer standalone portables (not installed) so may have to fiddle a shim to run on demand.

Great job done and F1 seems on first run not working (unpacking ??) but eventially appears twice as I also used menu :-)

[GitHubRulesOK]

Just to comfirm I got an unofficial build by
1 add a go.cmd pointing at standalone copy of go.exe
2 after several fails realised the bin folder are all 32 bit EXCEPT makeLZMA so run its SLN 1st with edit tools version to v142 !
3 add a custom version h to show it not official
4 add the blockers to Win11 specific entries as before.
5 set everything V142
6 be impressed that the help system is 1.3 MB exported and faster when wait for it to decompress first :-)