VAST 14 Execution Problem on Windows server 2008 R2

[Dusty]

Hi All

Just tried to launch our app after upgrading to VAST14 and get an error (Screenshot Attached).

Application popup: Archie2WebApp.exe - Application Error : The application was unable to start correctly (0xc0000005). Click OK to close the application. 

There are no further details in the windows logs and no walkback or dump file is created. Basically I have no idea or information on why this is suddenly failing. Reverting back to the 13.0.0 runtime works fine.

Any ideas on how to diagnose this problem?

[Mariano Martinez Peck]

Hi,

Could you please list which command line arguments are you passing to VAST in your Windows Service?

Regards,

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/d198b99b-a6c7-4808-8ebe-b9d1a24ebff3n%40googlegroups.com.

--

Mariano Martinez Peck VAST Lead Consultant Senior Software Engineer  mp...@instantiations.com  @MartinezPeck  /mariano-martinez-peck  instantiations.com

[Gareth Cox]

Hi

None, there are no command line arguments

Regards,

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibH3g5VTfb7bRMRdb3vEYecyb_UAKhjzkWtViwBYM6zv7g%40mail.gmail.com.

[Mariano Martinez Peck]

Hi Gareth,

A couple of thoughts:

1) Be sure to use a 14.0.0 runtime distribution (VAST VM binaries, ICs, etc etc) with your 14.0.0 runtime image. 

2) Add the command line argument "-l" to your windows service and specify a log file. For example, -lArchie2WebApp.log  and look for that file. If no name is specified, I think a default <serviceName>.log is created. Read more here: https://www.instantiations.com/vast-support/documentation/1400/#page/ug/vaug168.html

3) Check the Windows Event Viewer to see if anything useful was written there.

Let us know if that helped. 

Kind regards,

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/333a9853-0ce2-4dff-9d55-348d3b4ae7e4%40gmail.com.

[Gareth Cox]

Thanks Mariano
I use the runtime supplied by instantiations. To be clear, this works on all other distributions, including my ubuntu distribution.
I'm only experiencing the problem on windows server 2008 R2 Enterprise.
I'm not running it as a service yet, just double click the exe and get that error.
Event Viewer shows the text I previously posted:

Application popup: Archie2WebApp.exe - Application Error : The application was unable to start correctly (0xc0000005). Click OK to close the application. 

With no further information.

I tried the command line with -l and no log is created (it doesn't get far enough to do that?).

This is why its hard to diagnose. I'm not getting any information about why its failing to start.

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibHMCmpvsnT7iw9Pd%3DSNjc-yCHAuzTmibk0kbAVn_0Xy7w%40mail.gmail.com.

[Marcus Wagner]

Can you check Windows server 2008 installation (event log, sfc /scannow, pending or missing updates)?

Two directions to search:

1) It is likely that Windows refrains from starting any newly built EXE, requiring newest Windows support (eg. Kernel or DLLs)

Check the Windows event log. e.g. it can be that the new EXE requires newer Windows support than provided by 2008.

2) As server it might also be a matter of security, that is Window denies execution of any (suspect) EXE. In such cases security rules must be updated to allow for a new version of exe. 

For short, it might be not a matter of VAST, but a restrictive security policy or a result of the age difference (2025 vs. 2008).

[Marcus Wagner]

Besides I forgot a triviality which may also cause this : bitness. You cannot start a 64 bit version in a 32 bit environment.

[Gareth Cox]

To be clear, the exact same application but built with VAST 13.0.0 works fine.
Everything else on the server works fine.
Windows event log lacks any details other than the single line of text in previous message.
If it was security, would it not also stop the 13.0.0 exe from running as well?
Everything is 64bit.

--

You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/6d918a37-3751-44d7-8641-c539a15e0c36n%40googlegroups.com.

[Mariano Martinez Peck]

Hi Gareth, 

That's strange. Please feel free to open a support ticket in the VAST Support Portal: https://vast-support.instantiations.com/ 

Kind regards,

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/a07481a3-5d42-4c70-9a62-aaff6fd817e3%40gmail.com.

[Marcus Wagner]

I just installed a Windows 2008 Server and Instantiations and attempted to run environments. The program cant be started because of missing 

api-ms-win-core-synch-I1-2-0.dll. That means, the runtime system of VAST now needs a newer C++ support than that which was available in 2008.

As I wrote, a case 1.An installation of C++ support would potentially close the gap, if MS provides backward support of a newer Visual Studio (used to build VAST) to be able to run in an older Windws 2008 Server environment.

Dusty schrieb am Dienstag, 6. Mai 2025 um 10:35:34 UTC+2:

[Gareth Cox]

Thanks Marcus

That is interesting. I'm not running a development environment on the server. Is that how you got the extra information?

I'm interested how you figured that out (for my own education).

I think the fix for me is to convince the powers that be to let me upgrade our server (Perhaps even move away from windows).

--

You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/8e4f0c4d-1fc3-42a6-a600-3f2eacbe1d32n%40googlegroups.com.

[Noschvie]

Wouldn't it be easiest to do an in-place upgrade from Windows Server 2008 R2 to Windows Server 2012 R2?

[Marcus Wagner]

To be more precise your symptom is: 

the VAST 13.0 abt.exe (VM) is about two years older and may run, the VAST 14 abt.exe is newer and it fails to run in a 2008 environment.

Case 1

Although it is (almost) irrelevant, whether the image to be run is newer or older (except that the image must be compatible with the VM and its resources  to be used). (almost only: from times to time the image format changes, too), I have to clarify for me: 

as you said, you built an image with VAST 13.0 and run it with abt.exe 13.0, so lets say this image is image 13.0, and that combination runs ok under Windows 2008.

And then you build this ST code in a VAST 14.0 as image 14.0 and run it with abt.exe 14 and it failed. 

Or did you run the 13.0 image with abt.exe 14 or vice versa? Or are some silent dependencies broken, e.g. paths, ini files, etc)?

To track case 1 further is there any image which can be run with vast 14 or does it allways fail on any usage (this would indicate a faulty installation)?

Now to case 2: security can deny execution of any exe individually. So it is possible to allow 13.0 and to deny 14.0 or any other version. 

This might be an issue of incomplete configuration (of newer, later added products). 

This happens particularily in high security environments, where "exe"s and their execution are permitted to run only after a thorough investigation process. 

Rules may even deny execution when started from a different place, so the directory where the exe is located is also important (besides from access rights to be granted there).

Windows security usually does not say loud why it refrains execution.

It usually sends a terse, cryptical message like in this case.

You have to inspect the event.log (requiring admin privilege to find out more details). 

This restrictive Windows behaviour is obvious in a critical situation while blocking further attacks.

The kind of error ...000005 is a hint in this direction, that is a security violation / misconfiguration or other security issue.

Therefore more background information from Windows is needed to clarify this.

Another way here is to trace the execution from outside with some tool, e.g. procmon.exe from sysinternals. 

This also requires admin rights.

And sorry that I forgot that Windows 2008 Server was the first server version which was only available as 64 bit. 

This reduces the scope of conflicts where a Windows 64 bit exe of 2025 does not run anymore under Windows 2008 64 bit.

This also may happen. 

Certain Microsoft features introduced later in Windows may fail under older Windows if (backward) support is not provided there( requiring a retro fit). I had such situations with MS Visual Studio Code Version 6 and later (in combination with different newer Windows Versions).

This is rare. This may be resolved sometimes by additional (backward) feature installations (most likely supplying newer MS DLLs).

However, I do not know how VAST VMs are built and if this is of concern here.

[Marcus Wagner]

I was always fascinated with processing optimizations, so I gained a lot of insights there. As Windows 2008 server (and the bitness) was mentioned it just was eager to find out if and how the actual VAST behaves in an ancient environment. I dived into my archive and lost plenty of time to get a 2008 server virtual instance up and running. To find answers quickly and to compensate I thought about how to reconstruct the original problem: that rquires a VAST runtime environment, an image and as mentioned, tools for investigation. Tiny images are the environments.icx, the ibmst.icx and the abt.icx. A client installation of VAST will setup the VM and these images quickly. Having a client will also open the way for further investigations if needed. I remembered also that at that time (long ago) C and C++ had changes in their runtime support (DLLs changed internally between Visual Studio 6 and 2010~) - and with the impression, that the Smalltalk engine was written in C/C++ (ENVY 2 -  3 of OTI in the early 90ies) 

I thought : try it simply - just install VAST in the old enviroment and start it. 

Bingo.

From other past experiences I knew the need to install matching runtime support families (Visual C++ xxxx Redistributables) is wide spread, so to close gaps between the actual OS version and the DLL runtime support.

So to the conclusion: in lack of practical experience about efforts I cannot judge about whether implace upgrades of OS instances designated to run VAST is cheaper than the search and installation of a matching Visual C++ Redistributable (if such exists, its a guess).

So I close the circle of thoughts - effort is always needed to make old software runable in a new surrounding, no matter how compatible things are (I remember night mares about version changes of programming languages keeping the same machine/OS environment).

Gareth Cox schrieb am Freitag, 9. Mai 2025 um 08:22:32 UTC+2:

[Marcus Wagner]

That depends on the usage of the involved server instances (and its dependencies) and will gain only 4 years of progress (2012-2008).

:-)

Too, personally I am happy to be able to run Envy 3.0 - 5.0 in a modern environment if necessary, but I do not like to develop anything in it anymore.

From the development aspact, i clearly prefer vice versa VAST 14 in an older environment - but not so antique, if possible. 

:-)

I am wondering - still working machines of that time are rare, slow and became expensive when being turned on (costs of energy) - software of same age however seems to be abundant.

[vcost...@gmail.com]

I've heard of these problems before and the solution was to rebase certain DLLs. I have no specifics on it because I didn't work in that group. However, maybe someone here will know more.

[Mariano Martinez Peck]

Hi,

I think it's worth trying to install https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170  on that Windows Server 2008 R2 and see if that helps.

(pick up the correct bitness)

Regards,

--

You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/ac2a8b09-6de8-45fc-a2e1-823385a517e1n%40googlegroups.com.

[Marcus Wagner]

Thanks, see my private mail elsewhere.

[Marcus Wagner]

Mariano,

I am just about to follow your suggestion in detail. That might turn out unpleasant. 

To realise your suggestion, as advised by Microsoft, one has to install Visual C++ Redistributable installs Microsoft C and C++ (MSVC) runtime libraries BEFORE installing VAST and attempting to run it (either a self build, packaged VAST application using the VAST runtime distribution package or, as a developer, the VAST environment partially or as a whole). 

However, to choose the correct Visual C++  Redistributable, Microsoft demands in detail

The Redistributable version must be at least as recent as the MSVC build toolset used to build your app. We recommend you use the latest Redistributable available for your version of Visual Studio, with some exceptions noted later in this article.

Your app = VAST Smalltalk VM  built or using MSVC by Instantiations.

As Smalltalk user, that leads to the important question 

Which Visual Studio Version was used (by Instantiations) in which VAST version to prepare and install the correct match offered by Microsoft, to be able to run Smalltalk deliverable at arbitray Windows targets?

Hm.

Kind regards

Marcus

I guess the lastest 14.44.35112.1 for VAST 14 [assuming that  Visual Studio 2015, 2017, 2019, and 2022 was used] has to be installed in

Windows Server 2008 R2.

I will try that soon.  

As Microsoft already claims exceptions of this rule, I can imagine that this combination is not adequate for any of the long list of VAST versions in combination with e.g. Windows 2008 R2 or later.

Mariano Martinez Peck schrieb am Samstag, 10. Mai 2025 um 02:17:29 UTC+2:

[Marcus Wagner]

Hi Mariano,

I can reproduce the problem. 

Under 2008 R2 the VAST VM establishes a file lock in / about api-ms-win-core-synch-i1-2-0.dll and then immediately exits the thread and process, just about after investigating an image file execution option registry key (I guess, an optional debugging hook).

It was a long way for me to establish a 2008 R2 instance, make it actual, install the right Visual C+ 2008 Redistributable (9.0.30729.6161) and a runable process monitor (sysinternals v. 3.84) and then to install VAST 14.

My conclusion is although it first looked like the (then) new application lock windows feature in Win 7 / 2008 is the reason, but this is not the cause, although that might be the next problem.

I guess more it has to do s.th with the single instance feature of the VM. It does not matter, whether you actually use the -singleInstance option or not.

Anyway, the VAST.EXE process dies just when the VAST VM initializes its work, before a Smalltalk code becomes active.

Concerning the suspicious application lock facility, a couple of other things here are not in order. 

E.g. it is impossible to establish hash based rules on any VAST exe,  e.g. the AppLocker claims: 

"" is not a valid Win32 application (Exception from HRESYKTL 0x800700C1.

For me it seems that in establishing application lock Windows 2008 became very sensitive on any manipulation of executables, dll, exe or com.

And Windows 2008 R2 thinks, that abt.exe, environments.exe, nodialog.exe are manipulated and unclean. The will not be treated correcly by the app locker, even if they would run correctly.

This means you cannot run any VAST14 executable under Windows 2008 R2, no matter of whether you establish an application lock rule or not.

May be the way how to create initial execution stubs became unsecure, according to Windows. It knows, that environments.exe stems from nodialog.exe and judges it manipulated. Can be, that the associated manifests contribute to that. And another aspect, application lock also support signed executables, and there are none in VAST.

So there are at least two severe problems hidden in here. 

I did not attempt to install emsrv.exe to test if it also fails. 

emadmin can be run without a complaint (by Windows).

And I cannot judge how MS changed it strategy here, as all these programs run in newer Windows versions. However, i did not attempt to apply application locking here.

-

Marcus