x

Sign In

Email Address


Titanium Schedule - Support Portal


back
Shim error at start
Ticket: 5576
Created: 7/24/2014
Modified: 5/10/2016
Rating: No one has rated this article yet
Was this helpful? Yes   No
print

Users are getting a "SHIM" error pointing to .net framework when they start the Ti10.exe application.

There are several things that can cause this error:

 

Scenario 1: User states that it is working fine on 3 of the 5 PCs, but 2 are getting this "Shim" error.

IT Group recently updated the network path of the Ti installation directory to [Ti10] from [TitaniumSoftware] due to the Fully Qualified Domain Name causing the filename length to become too long.

After the FQDName update, the 2 PCs started having this problem.

Microsoft issue and fix: http://support.microsoft.com/kb/2715633

First try uninstalling and reinstalling the .net framework on the PCs.

Forcing the Group Policy to reapply (gpupdate /force) and rebooting corrects the issue, but if you close and reopen the software, the error returns.  If you experience this, you should speak with your back end network team, and let them know that it appears these machines are not getting the updated policy information for that new network location and it is causing an error when trying to launch the application.

Scenario 2Error: "This application could not be started"

Error message: This application could not be started.

Cause:  The app is not configured in a way that makes it possible to determine the appropriate version of the .NET Framework runtime. The corresponding shim code is SHIM_NOVERSION_FOUND.  Microsoft SCEP or other anti-malware/anti-virus application(s) altering folder or files.

The most recent update to SCEP I could find is: https://support.microsoft.com/en-us/kb/3036437

Proving SCEP to be the issue - running Ti10.exe from, e.g.,  T:\TitaniumSchedule\Ti10.exe doesn't work but, copying the root Titanium folder into a subfolder of the same works (like this - T:\TitaniumSchedule\Ti10FIXED\Ti10.exe).",  this is usually indicitive of SCEP interference. 

Proving Titanium application to not be the issue - the attached file is a very basic .NET application completely separate from Titanium.  Placing it into the Titanium shared application folder and executing should show that no .NET application can run from this folder.

Resolution: remove the Titanium Schedule application folder from SCEP/am/av scans.  Alternately to fixing the SCEP issue, you could change the desktop shortcuts to point to T:\TitaiumSchedule\TI10FIXED\Ti10.exe.

 

Additional info on Scenario 2: we've had reports of other database applications experiencing this same issue.  Basicaly, broken by the most recent SCEP update.  Via System Center Config Mngr, excluding the application from both the “Excluded Processes” and “Excluded Files and Locations” seems to have fixed it.

https://www.microsoft.com/en-US/Search/result.aspx?q=exclude+processes+SCCM



See attached for just about the simplest .NET (WinForms) application possible.
This executable is intended to show whether .NET Framework 4.0 is properly installed and can successfully execute .NET applications.
Successful execution will result in the screenshot below.  It is pretty straightforward.

Successful dotNetFrameworkTester

 

In the zip there is also an appropriate config file, which has an entry about loadFromRemoteSources - the one big oddity about Titanium Schedule's config that might throw some centers for a loop (as it overrides normal .NET security behavior that would otherwise sandbox the application due to running over a network share).


Attachment: dotNetFrameworkTester.zip