Application crashes on a terminal server

One of our customers experiences crashes with our software on a terminal server (Windows 2008 R2).
Our sofware is written in Clarion 8.
It seems that only users on a terminal server experience these crashes.

An application error (1000) can be found in Windows Event Viewer.
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll.

This is one of the lines of code where the software crashes sometimes (only a few times a day):
FILEDIALOG(DOSDialogHeader,DOSTargetVariable,DOSExtParameter,FILE:KeepDIR+FILE:LongName)

The current path is set to a UNC path like \\server1\…

Any ideas or experiences with this bug?

Hi!
Try mapping UNC path to letter.

Hey! Try signing your application *.exe files with TSAWARE flag (using MS editbin command). Alternatively, you could use the “Disable Visual Themes” compatibility checkbox to run your app.
Please be aware that changing the TSAWARE flag does carry quite a few assumptions about your app, so do your research. In the meantime the “Disable Visual Themes” flag should be sufficient to keep your app from crashing. Feel free to contact me for more info.

https://docs.microsoft.com/en-us/cpp/build/reference/tsaware?view=vs-2019

I traced an issue like this once to a specific bug in this version of Windows server. It was traumatic though so I have blocked the details.
Something about patch levels and FILEDIALOG was a trigger. Client was upgrading the server anyway so we didn’t have to work around it in the end.

2 Likes

This is a well known Windows bug. FILEDIALOG function opens Explorer window. If Explorer process starts on the same as your application CPU kernel, everything is ok. But if explorer process starts on any other CPU kernel, application crashes.
So, the solution is quite simple: Explorer prosess must start on the same kernel.
You may set this options manually using Control Panel (Folder options \ Browser Settings) or programmatically, using SetProcessAffinityMask() API function.

Hi,

We also had similar problem with FILEDIALOG on Citrix server. My solution was to prime DOSTargetVariable with the full path which included some bogus file name with the valid extension from DOSExtParameter

HTH
Leonid Chudakov
[email protected]

1 Like