vDos starting long time

[radovan]

Since 1-2 weeks, vDos takes much longer to start. It is different, from immediatelly until 50"...
My assumption is that this has to do with recent Windows updates, as this issue appears (only) on Windows Version 2004 and incl last updates. 2004 2 weeks ago worked fine.
I compared to also one PC with older Windows Version 1909 where it seems to work fine as earlier. 

Any idea how to fix this issue with the recent Windows releases (Version 2004)?

Thanks and regards
Radovan

[Jos]

vDos should display its window in at most 2 seconds, a DOS app gets this timeout to come with content and accept keyboard input.

I guess your anti-virus program is scanning vDos.exe over and over, sometimes connecting to the Internet? What if you temporary disable that?

Jos

[radovan]

Thanks for the answer.

No, anti virus is not the problem, I disabled it, but with the same issue.
It is quite obvious, a PC (with the same security configuration) with Windows 1909 works without problems. In the last couple weeks nothing changed within the IT infrastructure, except recent windows updates, based on the 2004 release.

There might ab any additional (security) check during the start with last updates...

I've t ried also with several compatibility configuration, reduced also UAC to minumum, but no help.

Radovan

[Jos]

I can’t replicate this behavior.

Could you start vDos with the log option (….vDos.exe /log).
The generated vDos.log file will at least show if the hiccup is caused before vDos starts, or when vDos is running.

Jos

[radovan]

vDos version: 2014.07.18
System OEM codepage: 850

DOS-Multiplex unhandled call 1687
DOS-Multiplex unhandled call 7A00

[radovan]

It is an older and licensed version. I tried also the newest one to test, but with the same behaviour

[Jos]

More recent versions of vDos have timestamps in the log file. So that would clarify if the hiccup is before or during vDos running.

Jos

[radovan]

Here it is (I've masked some confidential data with **)


vDos 2020.03.01
C: => (Local) c:\vDos\
C: => (Local) c:\vDos\VibuMW\
X: => (Remote) \\*.*.*.*\Daten\VibuDat\
A: => (Remote) \\*.*.*.*\Archiv\
D: => (Local) D:\
E: => (Local) E:\

21.07 Execute: vicx.exe - c x:\2020\***
Int 23 => 199:0438
Int 21 => 199:02c0
OpenFile failed: EMMQXXX0(2) => c:\vDos\VibuMW\EMMQXXX0(2)
OpenFile failed: $MMXXXX0(2) => c:\vDos\VibuMW\$MMXXXX0(2)
OpenFile failed: QMMXXXX0(2) => c:\vDos\VibuMW\QMMXXXX0(2)
OpenFile failed: EMMXXXQ0(2) => c:\vDos\VibuMW\EMMXXXQ0(2)
OpenFile failed: QEMM386$(2) => c:\vDos\VibuMW\QEMM386$(2)
OpenFile failed: QDPMI$$$(2) => c:\vDos\VibuMW\QDPMI$$$(2)
OpenFile failed: QDPMIG$$(2) => c:\vDos\VibuMW\QDPMIG$$(2)
OpenFile failed: 386MAX$$(2) => c:\vDos\VibuMW\386MAX$$(2)
Int 2f unhandled call 1687
Int 2f unhandled call 7A00
CPU exception 0b (1bc)
21.31 CPU exception 0b (1e4)
21.35 CPU exception 0b (1b4)
21.39 CPU exception 0b (1dc)
21.42 CPU exception 0b (18c)
21.57 CPU exception 0b (194)
21.70 CPU exception 0b (1c4)
21.76 CPU exception 0b (19c)
21.85 CPU exception 0b (184)
21.87 CPU exception 0b (1d4)
21.90 Int 2 => 199:0672
CPU exception 0b (174)
22.00 CPU exception 0b (16c)
22.03 CPU exception 0b (17c)
22.04 CPU exception 0b (184)
CPU exception 0b (1cc)
22.06 CPU exception 0b (1ac)
22.07 Delayed logging, set w/o DOS call:
Int 8 => 199:0c1e
Int 9 => 199:0c6e
Int 1B => 199:7e62
Int 22 => original
Int 23 => 199:7e70
Int 24 => 199:120c
Int 2F => 199:7e82
CPU exception 0b (2e4)
CPU exception 0b (24c)
CPU exception 0b (244)
CPU exception 0b (2ec)
CPU exception 0b (184)
CPU exception 0b (1c4)
CPU exception 0b (1ac)
CPU exception 0b (244)
CPU exception 0b (1dc)
CPU exception 0b (2e4)
CPU exception 0b (24c)
CPU exception 0b (2ec)
CPU exception 0b (334)
CPU exception 0b (33c)
CPU exception 0b (174)
CPU exception 0b (2fc)
CPU exception 0b (224)
CPU exception 0b (20c)
22.09 CPU exception 0b (16c)
CPU exception 0b (164)
22.25 CPU exception 0b (164)
22.34 CPU exception 0b (174)
22.42 CPU exception 0b (184)
22.53 CPU exception 0b (1c4)
22.64 CPU exception 0b (1dc)
23.10 CPU exception 0b (334)
CPU exception 0b (2e4)
CPU exception 0b (16c)
CPU exception 0b (33c)
CPU exception 0b (41c)
CPU exception 0b (414)
CPU exception 0b (224)
CPU exception 0b (20c)
23.23 CPU exception 0b (2ec)
23.95 CPU exception 0b (3ec)
24.53 CPU exception 0b (1ac)
CPU exception 0b (3b4)
CPU exception 0b (40c)
24.54 CPU exception 0b (2fc)
24.73 CPU exception 0b (164)
24.82 CPU exception 0b (174)
24.89 CPU exception 0b (184)
25.00 CPU exception 0b (1c4)
25.06 CPU exception 0b (1ac)
CPU exception 0b (1dc)
CPU exception 0b (2e4)
25.28 CPU exception 0b (33c)
25.37 CPU exception 0b (3ec)
25.59 CPU exception 0b (334)
CPU exception 0b (3b4)
CPU exception 0b (2ec)
FindFirst failed: C:dpfad.mem (18)
CPU exception 0b (3f4)
CPU exception 0b (414)
CPU exception 0b (174)
CPU exception 0b (184)
CPU exception 0b (224)
CPU exception 0b (20c)
25.60 CPU exception 0b (1ac)
CPU exception 0b (1dc)
CPU exception 0b (2fc)
CPU exception 0b (1c4)
CPU exception 0b (2e4)
CPU exception 0b (3e4)
CPU exception 0b (224)
CPU exception 0b (20c)
FindFirst failed: X:\2020\***\*.ndx (18)
CPU exception 0b (2ec)
CPU exception 0b (334)
CPU exception 0b (2fc)
FindFirst failed: X:\2020\***\backupid.@@@ (18)
FindFirst failed: X:\2020\***\backup.001 (18)
CPU exception 0b (16c)
CPU exception 0b (3c4)
CPU exception 0b (1cc)
CPU exception 0b (1a4)
25.71 CPU exception 0b (3b4)
CPU exception 0b (33c)
CPU exception 0b (1d4)
CPU exception 0b (3c4)
25.75 CPU exception 0b (3f4)
CPU exception 0b (474)
25.76 FindFirst failed: C:fkey.dbf (18)
CPU exception 0b (3fc)
CPU exception 0b (404)
CPU exception 0b (46c)
CPU exception 0b (304)
CPU exception 0b (43c)
CPU exception 0b (414)
CPU exception 0b (174)
CPU exception 0b (184)
CPU exception 0b (1c4)
CPU exception 0b (1ac)
CPU exception 0b (42c)
CPU exception 0b (394)
CPU exception 0b (384)
CPU exception 0b (1dc)
CPU exception 0b (2e4)
CPU exception 0b (3ec)
CPU exception 0b (164)
26.00 CPU exception 0b (33c)
26.26 CPU exception 0b (3ec)
27.07 CPU exception 0b (334)
CPU exception 0b (2ec)
27.09 CPU exception 0b (384)
CPU exception 0b (37c)
CPU exception 0b (42c)
CPU exception 0b (394)
CPU exception 0b (16c)
CPU exception 0b (3b4)
CPU exception 0b (1a4)
CPU exception 0b (3c4)
FindFirst failed: C:dpfad.mem (18)
CPU exception 0b (2fc)
28.12 CPU exception 0b (1cc)
28.14 CPU exception 0b (344)
CPU exception 0b (34c)
CPU exception 0b (354)
CPU exception 0b (35c)
CPU exception 0b (364)
CPU exception 0b (36c)
CPU exception 0b (374)
CPU exception 0b (38c)
CPU exception 0b (39c)
CPU exception 0b (3a4)
CPU exception 0b (3ac)
CPU exception 0b (3bc)
CPU exception 0b (3cc)
CPU exception 0b (3d4)
CPU exception 0b (3dc)
CPU exception 0b (3e4)
CPU exception 0b (3f4)
CPU exception 0b (3fc)
CPU exception 0b (404)
CPU exception 0b (40c)
CPU exception 0b (424)
CPU exception 0b (434)
CPU exception 0b (43c)
CPU exception 0b (454)
CPU exception 0b (45c)
CPU exception 0b (464)
CPU exception 0b (46c)
CPU exception 0b (474)
CPU exception 0b (47c)
CPU exception 0b (484)
CPU exception 0b (48c)
CPU exception 0b (49c)
CPU exception 0b (4a4)
CPU exception 0b (4b4)
CPU exception 0b (4bc)
CPU exception 0b (4c4)
CPU exception 0b (4cc)
CPU exception 0b (4d4)
CPU exception 0b (4dc)
CPU exception 0b (4e4)
CPU exception 0b (4ec)
CPU exception 0b (4f4)
CPU exception 0b (4fc)
CPU exception 0b (504)
CPU exception 0b (50c)
CPU exception 0b (514)
CPU exception 0b (51c)
CPU exception 0b (524)
CPU exception 0b (52c)
CPU exception 0b (53c)
CPU exception 0b (24c)
CPU exception 0b (244)
CPU exception 0b (1d4)
CPU exception 0b (20c)
CPU exception 0b (224)
Int 21 => original
vDos ended by EXIT (0)

[radovan]

and autoexec.bat:


rem Programmpfad:
use c: c:\vDos\VibuMW

rem RootDatenpfad
use x: \\*.*.*.*\Daten\VibuDat\



use a: a:\
use b: b:\
use D: D:\
use E: E:\

rem Fibu-Start
c:
vicx.exe c x:\2020\***
exit

[Jos]

Don’t know if this was a run with a hiccup. But there’s is an extraordinary delay of over 21” between
use E: E:\
and
vicx.exe c x:\2020\***

Only disk activity is a query c:\vDos\VibuMW\vicx.exe exists (autoexec.txt is cached).
When your run it a second time, you again get a delay before vicx.exe c x:\2020\***?
Then that query would be the cause. Perhaps Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) will reveal what’s going on in Windows internals.

Jos

[radovan]

So, I located the waiting gap, it is always different, fast until 45", in this example are 8" waiting time, considering: C:\vDos\cscapi.dll NAME NOT FOUND

Any ideas?

-----

10:03:38.3391184 vdos.exe 4148 RegOpenKey HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\vdos.exe NAME NOT FOUND Desired Access: Query Value, Enumerate Sub Keys
10:03:38.3409411 vdos.exe 4148 CreateFile C:\vDos\cscapi.dll NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
10:03:46.7384009 vdos.exe 4148 CreateFile C:\vDos\VibuMw\VICX.EXE SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
10:03:46.7384821 vdos.exe 4148 QueryNetworkOpenInformationFile C:\vDos\VibuMw\VICX.EXE SUCCESS CreationTime: 09.02.2021 11:50:07, LastAccessTime: 11.02.2021 10:02:48, LastWriteTime: 12.10.2014 23:10:26, ChangeTime: 28.10.2019 20:38:32, AllocationSize: 01.01.1601 01:00:00, EndOfFile: 01.01.1601 01:00:00, FileAttributes: A

[Jos]

The pause is always caused by CreateFile C:\vDos\cscapi.dll?

No real idea what cscapi.dll is for, it isn’t used by vDos.exe directly. So would be some other DLL, though why isn’t then the next operation CreateFile C:\Windows\System32\cscapi.dll?
I ran PM on two systems, CreateFile C:\vDos\cscapi.dll wasn’t logged.

If it’s always CreateFile C:\vDos\cscapi.dll, you could reset the PM filter and look for operations directly after CreateFile C:\vDos\cscapi.dll.

Jos

[radovan]

I don't know really any more, it is not always this, it is also antivirus files..but I deinstalled them completelly, no chance. The only obvious thing are different Windows releases, what is hidden within the newest updates, no clue, but something it is... Need to consider something else, installing VMWare VMs probably...

Thanks an regards
Radovan

[Jos]

Could it be related to OneDrive?

Jos

[radovan]

No chance, I've deinstalled all garbage incl. OneDrive.. It must be some additional, stronger security checks with last Windows release, but what...