Fatal Execution Engine Error

[Guest]

Hello,

we have a strange Problem here. Having an Appplication written and compiled
in Net 1.1 This one is running perfect on Server2003 in TS if executed
directly. But if we start it through our ERP System over a helper-DLL we get
the Fatal Execution Engine Error!?

On the Server is Framework Version 1, 1.1 and 2.0 installed. Altough our
Program is compiled with VS 2003 using Net 1.1 the error in the eventlog is
from Net 2.0

Anyone have an Idea why this Application can run directly but cannot be
called through a helper DLL?

Thanks in advance

 

[MSDNAndi]

Simi,

I fear you did not provide quite enough information.

At first you do not say much about what type of application we are dealing
with exactly.
Then: What is the call from the helper-dll to your application like?
(e.g. Is it just instanciating a class or executing a program, referencing a
dll or using reflection?)
Is the helper-dll a .NET 2.0 dll?
In which runtime is the executable hosting the helper-dll running?

e.g. if a web-application is involved, which runtime is configured for the
ASP.NET?

I do not have the articles here but from the .NET 1.0 to .NET 1.1 comparison
I remember that usually execution of a .NET 1.0 dll would occur in the .NET
1.1 runtime unless you take specific measure to avoid that.
(Cross-Runtime-calls are not really a nice thing btw.)

The actual error might have even more different implications. Besides of
compatibility issues related to the runtimes, I would always look at
"permissions, permissions and more permission" issues if one application is
not working in a different environment. Be it file-system, com+/dtc, local
or group policies and so on...

Sorry that I cannot be of more help.

Andi

 

[Guest]

Sorry for forgetting mentioning the mean parts

The Application is written and compiled with Net 1.1
The DLL is late binded, two variables are set and then a form shown just as
it would be done when executing the *.exe file.

It is a Windows Application. Permission? I can execute the EXE so why should
the DLL call not be allowed?

Is that enough Information?

BTW: Can I force a Application using a specific .Net-Runtime Version? As I
see in the Eventlog that the App is handled by .Net Framework 2 thus it is
compiled with VS2003 (Net 1.1). Could that be that error? Would it change
anything if we convert the App to Net 2.0 and compile it with 2.0?

Regards

 

[Guest]

Hey Simi,

I am sorry that I will not be able to provide you with anything close to a
solution.

You did not mention what you refer to as "Application written and compiled
in NET 1.1" . The "one is running perfect on Server in TS if executed
directly" or "our ERP System over a helper-dll"?
Maybe check out this blog:
http://blogs.msdn.com/kaevans/archive/2005/11/15/493077.aspx
If your "ERP System" is a "native application", then the following stands:
"1.1 add-in to a native application (such as Office or Internet Explorer)"
"Computer with 1.1 and 2.0"
"Loads with 2.0 unless the process is configured to run against 1.1"

What I am saying is that your problem has two sides:
One is the "framework", the other one is the actual error.
The error might have a completely different reason.
You are running the "dll" under completely different permissions.
What if, e.g., you are using an XmlSerializer or webservice-proxy but do not
have the permissions to write into the temp-directory in one of the two
approaches.

So it might be that the "2.0" is causing the problem, but it might be
something else.

If a DLL is hosted by a process it generally runs under the permission set
of that process.
So if you run an exe stand-alone, it has your permissions.
(Be aware however, that a DLL being used by a process can be a
COM+-application and have it's own, different user-context due to that).
If you run it through another application, then you have to check, what the
permissions are that your application is requiring (directly, e.g. writing to
specific directories, or indirectly when for example the XmlSerializer
creates a temporary class) - and which permissions you actually have.

So I recommend:
1. Find out: Who is reporting the error exactly?
2. How is the execution path of the application (including your dll) until
there and what does the application "want" to do.
3. If you can modify the DLL, make it speak to you, say: add debug-output
(e.g. with #if DEBUG sections). (I do not recommend using a debugger for this
scenario as running a debugger changes permissions). So you can find out how
"far" the execution goes.
4. run tools to find out what is going on in the system...
http://www.sysinternals.com/
try "Filemon" first and maybe even "regmon"

In any case: It will involve sound analyzing.

From this information you provided so far, I fear, nobody really can tell
you what might be the problem.