Interrupt 0D #GP error dialog when printing in LARS

[hektech]

Using build version 1888.

When attempting to print reports in LARS (library bindery software), a series of "Interrupt 0D #GP" dialogs appear several times (I believe 3 times). If you "continue" through the prompts, the print dialog does appear, but the eventual printer output is garbled (lines are squashed).

Tests were then performed with EnumFontLimitation=1. The Interrupts still occur, but the printer output was correct. Additional testing might be needed to determine whether the output changes were chance related, or if the EnumFontLimitation=1 was effective.

In both cases, however, the program can no longer exit properly after printing. Attempts to exit lead to more Interrupt prompts, then an abnormal program termination prompt.

Attaching a trace which contains the initial print-related prompts, but with print then canceled, and no subsequent crash on exit.

trace_int.txt

[cracyc]

The problem is likely with a print dialog hook or template. Fixing it will be pretty much impossible without access to the program as the trace is too vague.

[hektech]

Thank you again for looking into this. I am hoping we can work out a way to proceed.

First, I could supply a copy of software somehow if you are interested. I am not sure how far you could get in actually running it, since the configuration is complex and bindery specific, but if access to the files is all that matters, we can make that work.

Otherwise, with some pushes in the right direction, I can put in the necessary work to get whatever you might need. Would additional debug statements help anything? Or what else should I look for? For context, I am primarily a Unix sysadmin who has done a large amount of client/server programming in Perl, with basic knowledge of other common languages. I have effectively zero Windows programming experience. So, while this is all quite foreign (and generally lower level than I have worked from a programming perspective), we aren't starting from zero 😄

[cracyc]

Don't necessarily need to run it, just a copy of the exe to analyze.

[hektech]

Well that's easy! Hope it gives you what you need.

LFWL.zip

[cracyc]

https://ci.appveyor.com/project/otya128/winevdm/builds/36837713/job/rf93iv65jnvenn21/artifacts might help.

[hektech]

cracyc, thank you again for you efforts. Unfortunately, this change does not appear to have made a difference. I am attaching a new trace which includes completing the print and then exiting the program. I am doing this because, after printing, the program will crash when trying to exit. The surface behavior is very similar, a series of interrupts. I thought it might provide another angle on the problem, if the cause ends up being related.

trace_int_2.txt

Hope there might be some more insight gained.

[cracyc]

Well, I can see what's happening just not why. Note it uses MFC20, source can be seen at https://github.com/DigitalMars/dmc/tree/master/mfc/SRC/16-BIT.

2d7c:Call USER.291: SETWINDOWSHOOKEX(0004,11ff2e08,119f,11df) ret=11ff:2f2b ds=149f
3248:2d7c:trace:hook:SetWindowsHookEx16 849: (4,11ff:2e08,119f,11df)
2d7c:Ret  USER.291: SETWINDOWSHOOKEX() retval=4b48000a ret=11ff:2f2b ds=149f
2d7c:Call COMMDLG.20: PRINTDLG(155f4580) ret=11ff:9a21 ds=149f
...
3248:2d7c:trace:msg:WINPROC_CallProc32ATo16 1833: (6442EF80, 002906F2, WM_NCCREATE(0081), 00000000, 0357A900)
2d7c:CallTo16(func=11ff:2e08,ds=149f,0000,0000,159f,1de0) ss:sp=149f:63ba ax=149f bx=0000 cx=0000 dx=0000 si=0000 di=0000 bp=63e4 es=149f fs=0053
2d7c:Call USER.136: SETWINDOWLONG(00c5,fffc,11ff2ddc) ret=11ff:2e91 ds=149f
3248:2d7c:trace:msg:WINPROC_AllocProc16_2 379: returning FFFF1002 for FFFF090F/16-bit (3/1024 used)
2d7c:Ret  USER.136: SETWINDOWLONG() retval=ffff1002 ret=11ff:2e91 ds=149f
2d7c:Call USER.292: UNHOOKWINDOWSHOOKEX(4b48000a) ret=11ff:2edf ds=149f
3248:2d7c:trace:hook:UnhookWindowsHookEx16 969: (4b48000a)
2d7c:Ret  USER.292: UNHOOKWINDOWSHOOKEX() retval=00000001 ret=11ff:2edf ds=149f
2d7c:RetFrom16() ss:sp=149f:63ba  ax=0000 bx=3bcc cx=0000 dx=0000 bp=63e4 sp=63ba
3248:2d7c:trace:msg:WINPROC_CallProc32ATo16 1833: (64431020, 002906F2, WM_NCCREATE(0081), 00000000, 0357A900)
2d7c:CallTo16(func=11ff:2e08,ds=149f,0000,0000,159f,1de0) ss:sp=149f:63ba ax=149f bx=0000 cx=0000 dx=0000 si=0000 di=0000 bp=63e4 es=149f fs=0053
2d7c:Call USER.136: SETWINDOWLONG(00c5,fffc,11ff2ddc) ret=11ff:2e91 ds=149f
...
3248:2d7c:trace:msg:WINPROC_CallProc32ATo16 1833: (6442D730, 000B093C, WM_SETFONT(0030), 200A132E, 00000000)
2d7c:CallTo16(func=11ff:9616,ds=149f,00c7,0030,00d8,0000,0000) ss:sp=149f:63ba ax=150f bx=0006 cx=0000 dx=0000 si=00c7 di=0000 bp=63e4 es=149f fs=0053
2d7c:Call KERNEL.55: CATCH(149f6366) ret=11ff:523e ds=149f
     AX=6366 BX=6362 CX=0000 DX=0000 SI=334a DI=638a ES=149f EFL=00003246
2d7c:Ret  KERNEL.55: CATCH() retval=none ret=11ff:523e ds=149f
     AX=0000 BX=6366 CX=0000 DX=0000 SI=334a DI=638a ES=149f EFL=00003246
2d7c:Call KERNEL.55: CATCH(149f6310) ret=11ff:25ae ds=149f
     AX=6310 BX=630c CX=3c46 DX=121f SI=00d8 DI=3c46 ES=149f EFL=00003246
2d7c:Ret  KERNEL.55: CATCH() retval=none ret=11ff:25ae ds=149f
     AX=0000 BX=6310 CX=3c46 DX=121f SI=00d8 DI=3c46 ES=149f EFL=00003246
=====dump all modules=====

Setwindowshookex is called to prepare the dialog call then printdlg is called at https://github.com/DigitalMars/dmc/blob/master/mfc/SRC/16-BIT/DLGPRNT.CPP#L118. The wm_nccreate message ends up in https://github.com/DigitalMars/dmc/blob/master/mfc/SRC/16-BIT/WINCORE.CPP#L274 where the hwnd is bound to a cwnd class and the hook is removed. The wm_setfont message is handled in https://github.com/DigitalMars/dmc/blob/master/mfc/SRC/16-BIT/DLGCORE.CPP#L34 where the cwnd class is retrieved but the hwnd is different (the nccreate message hwnd16 is 0xc5 while the setfont one is 0xc7). The 0xc7 hwnd has no cwnd so it crashes when it tries to use it. I've tried other programs that use mfc and none seem to have this problem so I don't know what is different about yours.

[cracyc]

Try https://ci.appveyor.com/project/otya128/winevdm/builds/36911947/job/8jq49fsbkfhv2h9u/artifacts .

[cracyc]

Have you had a chance to test this yet?

[cracyc]

The pr needs to be rebased but the artifact is still there for testing.

[hektech]

Sorry for the very long delay in replying. The rhythm of the academic year pulled me away from the project for a little while.

So, I tested this quickly way back in December, and did not see any improvement. However, that was fairly long ago, and I wanted to be more confident in that assertion, so I decided to test it fresh yesterday.

However, oddly enough I could no longer recreate the problem I was experiencing! I could do so neither on the linked build (1900), nor on an older build without this patch.

I do not know what to make of it overall. Obviously, the computer has received regular updates and restarts over the last few months, so something could have changed. Is there any real chance the problem was somehow state related?

At any rate, I did not see improvement with this patch back in December, but I also no longer have the problem now. Unless it comes back, or someone has an idea on making it come back for testing, I think we should consider this issue to be invalid with no necessary changes.

Thank you, once more, for all of your work on this project. It is a huge help for us.

[cracyc]

I'm quite sure the patch was on the right track even if it wasn't entirely correct. Since the problem was in the behavior of msctf in windows 10 I wouldn't be surprised if microsoft made some change the solved or at least hid the problem. Anyway, if it's working you should close this issue.

[hektech]

Okay, will do so now. Fingers crossed.