forums.silverfrost.com

craiggw · Joined: 30 Nov 2006 Posts: 3

Hi
When I open up a fortran file or create a new fortran project I get the runtime error:

>Microsoft Visual C++ Runtime Library
>Runtime Error!
>Program:...Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe
>This Application has requested the Runtime to terminate it in an unusual way.
>Please contact the applications support team for more information.

I used to be able to open, create and edit fortran files without a problem. This runtime error has arisen since the server was updated.
Any suggestions would be greatly appreciated
Cheers
Craig[/img]

PaulLaidler · Posted: Tue Dec 05, 2006 8:16 am Post subject:

You may have to re-install Visual Studio and/or .NET.
Make sure that the two are compatible (i.e. 2003 goes with .NET 1.x).

craiggw · Joined: 30 Nov 2006 Posts: 3

Yeah we reinstalled .Net and FTN95 and the 4.91 patch. The two are compatible as the only thing in the system that i different is there is a new local server. do u happen to know whether a replacing a server can alter environment variables that affect FTN95?

richardh · Joined: 06 Dec 2006 Posts: 4 Location: NZ

To add a little more info:

The change that was made was basically new servers and a new domain, and the dev boxes were set up to point to the new domain.

We have completely uninstalled and reinstalled vs.net 2k3 & sp1 and salford fortran + patch, and have both .net 1.x and 2.0 installed.
We have tried leaving the new domain and logging in as local admins, and checked the antivirus is not conflicting.
We tried loading old projects and creating new ones.
In all cases, we get the original error.

When we ran vs in safe mode, we got an error that the FTN95 plug-in did not load properly.

What would be really good would be if you could show us how to get debug messages out of ftn95 so we can see what is going on before it crashes. Can you help in that regard?

Obviously this is a serious problem, and the longer that it remains unresolved the worse the worse that ftn95 looks in the eyes of our management. I would appreciate a fast resolution to this.
_________________
Regards,

Richard.

PaulLaidler · Posted: Thu Dec 07, 2006 8:21 am Post subject:

I guess that this has to be a problem either with VS or with the VS plug-in for FTN95. I have not seen anything like this before but will pass on your query to the author of the plug-in.

A plug-in for VS 2005 is about to be released which may help.
If any changes have been made to the plug-in for 2003 then they will only be minor.

richardh · Joined: 06 Dec 2006 Posts: 4 Location: NZ

We rebuilt a machine yesterday without joining our new domain and FTN95 runs fine for the local admin of that machine. We then joined the domain and logged in with a domain user (with local admin rights) and it failed for that user. The local admin still works though.
Investigating, we discovered that logging in as different users on our new system actually changes the HKEY_CLASSES_ROOT part of the registry. Specifically the entries for .ftn95p were missing for the users that were part of the domain. We don't know what else is changed, but it seems that the problem is at our end. I will post more when we find it out, as other users may encounter this problem.
_________________
Regards,

Richard.

Andrew · Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany

This does sound like it could be a registry issue related to users. The Visual Studio plugins write entries to HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT. They should generally be installed by an Administrator (potentially a domain Adminstrator in your case) and the option to install for all users should be selected.

richardh · Joined: 06 Dec 2006 Posts: 4 Location: NZ

Yes, it is quite bizarre. It seems that logging on to the new domain causes entries under HKEY_CLASSES_ROOT (or possibly the entire section) to be replaced. Certainly the .ftn95p entries vanished.
I have no idea how or why this happens.
We seem to have found a way forward though. When I deinstalled FTN95, I did it by running the installer, which appears to deinstall the package (and then again to reinstall). However, we noticed that there are two packages installed, the core and the VS plugin, and I think that perhaps the plugin did not get deinstalled when we did it my way. Doing this from the add/remove programs dialog seems to work.
_________________
Regards,

Richard.

richardh · Joined: 06 Dec 2006 Posts: 4 Location: NZ

Just to finish this thread off with the best method of fixing this:

When you uninstall, you must not use the installer (even though it seems to work) as it doesn't seem to uninstall the VS plug-in correctly. Instead, use the uninstaller from the add/remove programs dialog.
Start with uninstalling the plug-in, and then the main app, and then reinstall.
In my case, I had to run the self extracting exe in order to recreate the ...vs2003.msi file that was required by the uninstaller, and then terminate that process using the task manager (and then cancel the installer which it had started).
_________________
Regards,

Richard.

Andrew · Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany

I would always recommend uninstalling the VS plugin from Add/Remove programs - I will get the documentation updated to reflect this.

If anyone is interested - it is possible to extract the .msi files from the self-extracting main .exe. The self-extrator has been created using 7-Zip found at:

http://www.7-zip.org/

You can use 7-Zip (or presumably other zip utilities, but why use anything else? 7-Zip is probably the best out there in my opinion!) to extract files from the .exe if you require access to the VS plugin installers directly.