AppCrash in Win 10 1809 and Asian IME input

[VigoF]

Hi
i've stumbled upon a nasty issue. I've been using VDOS for a while for our legacy application, but now on couple of brand new machines it fails to run, the application does some initialization as it creates a few lines of logs, but then derails. Also the included demo application fails. Windows tracks an error of vdos.exe in event log.

The combo appears to be VDOS 20180530 + Windows 10 1809 64 bit + Asian IME.
Behavior: black VDOS window appear for a few seconds, then closes down. Windows tracks error 0xc000041d offset 0x00058c85
This happens when active keybord layout is set to an Asian IME, such as Japanese or Chinese.
Incredibly, if i set keyboard as ENG, VDOS runs fine.
So for now the only workaround i've come up with is to switch keyboard to ENG before the DOS program is needed, which is quite nonsense.

I am not sure this is the only combo which raises the issue. I've several workstations running a wide array of w10 from 1607 to 1803 in different countries, although i'm rolling out OS upgrades from win7 in Asia recently, so the number of them is still low and not all of them use their IME.
I suspect this is one the bugs introduced with the infamous 1809 upgrade. I've been doing some research but can't find out much as possibly most of the articles are in asian languages and/or this hits a very thin area of the system which no other program than VDOS uses...

Let me know if i can provide anything else useful to investigate the issue.

Error stack from event viewer:

Faulting application name: vDos.exe, version: 0.0.0.0, time stamp: 0x5b0e2f26
Faulting module name: vDos.exe, version: 0.0.0.0, time stamp: 0x5b0e2f26
Exception code: 0xc000041d
Fault offset: 0x00058c85
Faulting process id: 0x2f5c
Faulting application start time: 0x01d4d3426d4cff1b
Faulting application path: D:\vDos\vDos.exe
Faulting module path: D:\vDos\vDos.exe
Report Id: d42ad272-ccee-47df-a868-e775f9bfbd83
Faulting package full name:
Faulting package-relative application ID:

[Jos]

I didn’t know vDos is used at all in Asian countries. I assumed due to the difficulties of DOS handling those languages, Asian people would by now all have switched to Windows programs.

My first suspicion is vDos assuming unicodes are just always 2 bytes as it builds its ASCII to Unicode table. If you start vDos with the log option (“…\vDos.exe” /log), does it create a vDos.log file with at least the first line showing the vDos version? So we could then start tracking down at what step vDos misbehaves. Probably best to switch to direct email communicating for that.
One question beforehand: What codepage is reported by the Windows command prompt with Asian IME?

Jos

[VigoF]

Mind that we're not talking about the possibility to input Asian text, but just run a program that does some processing without any user input, which on earlier builds of win10 apparently had no issues.





A bit more on che configuration of my test machine, for everyone to get the scenario:

The non-unicode settings are Japanese, command prompt CHCP returns code page 932


This allows non-unicode programs to display correct symbols, it has the odd effect to display the directory separator "\" as "¥"

in explorer, so our root of vDos looks like D:¥vdos¥vdos.exe





Windows 10 allows to also choose the GUI display language, i've seen that being irrelevant to the issue, i'm currently logged in displaying english language.



We have the option to choose which input (keyboard layout) to use







You can choose conventional input (type 'watashi' straight input 'watashi') or enable microsoft IME for Japanese (type 'watashi' becomes わたし and pressing space it prompts to replace them with the kanji 私 )





What causes vDos to crash is simply the fact of having selected IME input method at runtime.
If it's set to ENG, no prob.
I can start a vDos prompt as english and switch to IME afterwards, no effects, so it seems an "initialization" problem.

This is the log running the test program when ENG is selected.

vDos 2018.05.01
    0.07 C: =>  (Local) D:\vDos\

    1.98 Execute: DP26YI.EXE -  /s
    2.07 Delayed logging, set w/o DOS call:
         Int 1B => 2a0d:0004
         Int 22 => f000:0003
    2.95 FindFirst failed: DP{S0001.TMP(18)
         OpenFile  failed: DPTEST\DP{S0001.TMP(2) => D:\vDos\DPTEST\DP{S0001.TMP
         FindFirst failed: DP{T0001.TMP(18)
         OpenFile  failed: DPTEST\DP{T0001.TMP(2) => D:\vDos\DPTEST\DP{T0001.TMP
         FindFirst failed: DP{I0001.TMP(18)
         OpenFile  failed: DPTEST\DP{I0001.TMP(2) => D:\vDos\DPTEST\DP{I0001.TMP
    5.07 Delayed logging, set w/o DOS call:
         Int 1B => original
    6.50 vDos ended by EXIT (0)
This is the log of same action having IME input selected

vDos 2018.05.01
    0.06 C: =>  (Local) D:\vDos\

It just hangs there.
I edited the test program startup script to just display the welcome message (removed the line call DP26Y), and another variant that simply runs the DIR command, same result.

If i run my DOS application in log mode the behavior is slightly different:

autoexec.txt

use d: d:\


set myvar=1


set path=d:\xxx\yyy;d:\xxx
d:


cd \xxx\yyy
mydosapp WS:1


exit
Log

vDos 2018.05.01
    0.03 C: =>  (Local) D:\vDos\IN\
         D: =>  (Local) d:\

         Execute: MYDOSAPP.EXE -  WS:1
         Int  6 =>  1a9:0994
         Int  6 => original
         Int 2F unhandled call 1687
         Int 2F unhandled call FB42

         Execute: D:\XXX\YYY\dpmi16bi.ovl
         Int 15 unhandled call C300
         Int 33 =>  2f8:0112
         Int 2F =>  2f8:03d0
         Int 21 =>  2f8:01cc

         Execute: D:\XXX\YYY\rtm.exe -  WS:1
         CPU exception 0d (0)
         CPU exception 0d (0)
         CPU exception 0d (0)
         CPU exception 0d (0)
         CPU exception 0d (0)
         CPU exception 0d (0)
         CPU exception 0d (0)
         CPU exception 0d (0)
    0.04 CPU exception 0d (0)
         CPU exception 0d (0)
[...]
         CPU exception 0d (0)
    0.65 CPU exception 0d (0)
[hangs - truncated]
My idea is that DOS application initializes but virtualization crashes in the moment something is to be displayed on screen.
What this app does at first is to display a '*' symbol then print a blue screen where it shows an ASCII progress bar. It doesn't reach that point, but it does some disk i/o before that.

I did some regression test:
Windows 10 x64 1803, vDos version 2017-09-16 and 2018-05-30 both runs OK on JAP and ENG input

*
Windows 10 x64 1809, vDos version 2017-09-16 and 2018-05-30 both runs OK on ENG input

and both FAIL on JAP input.

From ProcMon trace i can see when JAP mode is enabled it loops thru registry HKCU\Software\Microsoft\IME\15.0\IMEJP before crashing
That seems to be the case also on win 1803, but it doesn't crash.
Likely an API or something changed within 1803 and 1809...

* Note: my test on win 1803 is not 100% reliable as this build is known to have issues with IME (i can't install input pack for some stupid windows update errors), so i have the input mode but can only input western text. Will try to find some other combos to test the scenario.

If you want to test and debug locally, it's very simple to install Japanese IME, it doesn't have side effects (unless windows update module fails...), just ensure not set it as default display language! here's a quick guide www.coscom.co.jp/learnjapanese801/msime_win10_en1.html

And yes, if you wish to follow up via email you have my contact.
thanks

[Jos]

Meanwhile the issue was tracked down to the first 1809 Windows update that misbehaves when the keyboard is set to Japanese IME. It sends a WM_PAINT message premature while vDos is initializing its window, handling that message then invokes random vDos code called by Windows. It has been fixed, awaiting what the 1904 update will bring. If someone has the same issue, let me know.

Jos