Having great problem with an C# application

[Tony Johansson]

Hello!

We have a C#.ASP.NET application that runs on a IIS 6. The application
contains actually several asp pages but there is no GUI.
The application receive an xml file that is processed.
There is also an MFC dll that is called from this asp application to make a
syntax check on quite many commands.
You don't have to know what a command is.

The problem that we get is the following when the asp pages calls the MFC
dll it will crash in such a way
that the whole application pool on the IIS will be restarted. The IIS runs
on a windows server 2003.
We have added some rows in the MFC dll to write to a file about where in the
dll it is executing.and also
write some value for different variables.
We know exactly on which row in the MFC dll it will crash . We know also
that this row is used in
several other places in the code so we doubt there is an error on that row
but we are not
100% sure.

We have also build the dll in debug mode and copied it to the windows server
2003 and it
will result in the same error crash in the dll.

Another thing that is of interest is that if we run the built-in application
server in Visual Studio which exist by default we never get any kind of
error.
This is strange because when we run the built-in application server the asp
will call the MFC dll but when we run it in this way we never ever get any
kind of problem.

We have also copied and change the asp pages to be runable in a windows form
application which will call the
MFC dll and here we never get any kind of problem either.

If we look in Event Viewer when we have a MFC crash we can read the
following.
Note that there is two entry for this DLL crash in the Event viewer. The
three rows at the bottom is the second entry and is written with a few
seconds delay compared to the first entry.

An unhandled exception occurred and the process was terminated.
Application ID: DefaultDomain
Process ID: 6108
Exception: System.AccessVi olationExceptio n
Message: Attempted to read or write protected memory. This is often an
indication that other memory is corrupt.
StackTrace: at System.RuntimeT ypeHandle.Const ructName(Boolea n nameSpace,
Boolean fullInst, Boolean assembly)
at System.RuntimeT ype.RuntimeType Cache.Construct Name(String& name,
Boolean nameSpace, Boolean fullinst, Boolean assembly)
at System.RuntimeT ype.RuntimeType Cache.GetFullNa me()
at System.RuntimeT ype.get_FullNam e()
at System.Runtime. Serialization.S erializationInf o..ctor(Type type,
IFormatterConve rter converter)
at
System.Runtime. Serialization.F ormatters.Binar y.WriteObjectIn fo.InitSerializ e(Object
obj, ISurrogateSelec tor surrogateSelect or, StreamingContex t context,
SerObjectInfoIn it serObjectInfoIn it, IFormatterConve rter converter,
ObjectWriter objectWriter)
at
System.Runtime. Serialization.F ormatters.Binar y.WriteObjectIn fo.Serialize(Ob ject
obj, ISurrogateSelec tor surrogateSelect or, StreamingContex t context,
SerObjectInfoIn it serObjectInfoIn it, IFormatterConve rter converter,
ObjectWriter objectWriter)
at
System.Runtime. Serialization.F ormatters.Binar y.ObjectWriter. Serialize(Objec t
graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck)
at
System.Runtime. Serialization.F ormatters.Binar y.BinaryFormatt er.Serialize(St ream
serializationSt ream, Object graph, Header[] headers, Boolean fCheck)
at
System.Runtime. Remoting.Channe ls.CrossAppDoma inSerializer.Se rializeObject(O bject
obj, MemoryStream stm)
at System.AppDomai n.Serialize(Obj ect o)
at System.AppDomai n.MarshalObject (Object o)

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.3959, P3 45d6968e, P4 mscorlib,
P5 2.0.0.0, P6 4889dc80, P7 13ac, P8 35, P9 exception, P10 NIL.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.


I hope to get some information about this strange problem that we have.
For example I wonder about the row that cause the crash.
As I said before it sounds strange that there should be an error on that row
when it works when we run and call the MFC dll in two different local modes
which are.
1. Use Visual Studio and the built-in application server
2. Use Windows forms that call the MFC dll

//Tony

[Mr. Arnold]

Re: Having great problem with an C# application


"Tony Johansson" <t.johansson@lo gica.comwrote in message
news:OaTXdibOJH A.4088@TK2MSFTN GP02.phx.gbl...

Another thing that is of interest is that if we run the built-in
application server in Visual Studio which exist by default we never get
any kind of error.
This is strange because when we run the built-in application server the
asp will call the MFC dll but when we run it in this way we never ever get
any kind of problem.

The VS file based Web server on the development machine is not IIS. At the
very least, the Web server file based solution should have been converted to
run against IIS on the development machine.

To develop a solution to run against the VS file based Web server on the
development machine, solely if that is what has happened here, and never
running it against IIS on the development machine is a no no.

http://msdn.microsoft.com/en-us/library/ms164911(VS.80).aspx

[Tony Johansson]

Re: Having great problem with an C# application

Hello!

We don't have single clue what you are trying to say. Can you try to explain
in another way perhaps.
We just want to have as many suggestion as possible to how we can solve our
problem.

//Tony


"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
news:uak8dzbOJH A.4180@TK2MSFTN GP05.phx.gbl...

>
"Tony Johansson" <t.johansson@lo gica.comwrote in message
news:OaTXdibOJH A.4088@TK2MSFTN GP02.phx.gbl...
>

>Another thing that is of interest is that if we run the built-in
>application server in Visual Studio which exist by default we never get
>any kind of error.
>This is strange because when we run the built-in application server the
>asp will call the MFC dll but when we run it in this way we never ever
>get any kind of problem.

>
The VS file based Web server on the development machine is not IIS. At the
very least, the Web server file based solution should have been converted
to run against IIS on the development machine.
>
To develop a solution to run against the VS file based Web server on the
development machine, solely if that is what has happened here, and never
running it against IIS on the development machine is a no no.
>

http://msdn.microsoft.com/en-us/library/ms164911(VS.80).aspx

>

[Mr. Arnold]

Re: Having great problem with an C# application


"Tony Johansson" <t.johansson@lo gica.comwrote in message
news:OgGJPQcOJH A.1488@TK2MSFTN GP03.phx.gbl...

Hello!
>
We don't have single clue what you are trying to say. Can you try to
explain in another way perhaps.
We just want to have as many suggestion as possible to how we can solve
our problem.
>

What I am telling you is that you running that application in the VS IDE
using VS's file based Web server/application server is NOT the same thing as
taking that project from the start, using an ASP.NET project type and
setting that project up to run directly against IIS on a development
machine.

Obviously, the two project types are not the same. On one hand, the solution
running against VS's Web file based server/application is not blowing-up. On
the other hand, the solution is blowing-up when running against IIS.

Therefore, one must test the application in VS debug mode with the
application being a true ASP.NET solution to find out what is the cause of
the application termination which causes IIS to abort too.

You will most like have to convert the VS Web file based/application server
project over to a ASP.NET project that is using IIS to test the project in
debug mode to uncover what is going wrong, use Google to find out how to
convert the file Web based project type over to an ASP.NET project type
using IIS.

The information in the link is telling you the possible conditions of the
application abort, and it is obvious that the VS Web based file
server/application server could be more forgiving than that solution being a
ASP.NET solution tested and debugged against IIS on the development machine.

http://msdn.microsoft.com/en-us/library/ms164911(VS.80).aspx

>
>
"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
news:uak8dzbOJH A.4180@TK2MSFTN GP05.phx.gbl...

>>
>"Tony Johansson" <t.johansson@lo gica.comwrote in message
>news:OaTXdibOJ HA.4088@TK2MSFT NGP02.phx.gbl.. .
>>

>>Another thing that is of interest is that if we run the built-in
>>application server in Visual Studio which exist by default we never get
>>any kind of error.
>>This is strange because when we run the built-in application server the
>>asp will call the MFC dll but when we run it in this way we never ever
>>get any kind of problem.

>>
>The VS file based Web server on the development machine is not IIS. At
>the very least, the Web server file based solution should have been
>converted to run against IIS on the development machine.
>>
>To develop a solution to run against the VS file based Web server on the
>development machine, solely if that is what has happened here, and never
>running it against IIS on the development machine is a no no.
>>
>http://msdn.microsoft.com/en-us/libr...11(VS.80).aspx
>>

>

[Hans Kesting]

Re: Having great problem with an C# application

Tony Johansson explained on 29-10-2008 :

Hello!

I hope to get some information about this strange problem that we have.
For example I wonder about the row that cause the crash.
As I said before it sounds strange that there should be an error on that row
when it works when we run and call the MFC dll in two different local modes
which are.
1. Use Visual Studio and the built-in application server
2. Use Windows forms that call the MFC dll
>
//Tony

When you run your web-app this way, it runs under your own account,
which is probably a local administrator.

Under IIS it will run under a special account that has very limited
rights.

My guess is that that's the problem. And no, the solution will *not* be
to let the site run under an administrator account!

Hans Kesting

[Tony Johansson]

Re: Having great problem with an C# application

Hello!!

We have now a local IIS on our development computer.
We have not tested yet because we have to do some preparation before we can
test
if we get the same kind of problem when running a local IIS.

Most certain will we get the same kind of problem that we have on the
computer
where we run windows server 2003.

If we get the same kind of problem when running through the local IIS is it
in
any way possible to step in and debug the MFC dll that cause the problem ?

Our asp application project was created by using Open Website in VS.

//Tony

"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
news:uF3Mz5cOJH A.4304@TK2MSFTN GP05.phx.gbl...

>
"Tony Johansson" <t.johansson@lo gica.comwrote in message
news:OgGJPQcOJH A.1488@TK2MSFTN GP03.phx.gbl...

>Hello!
>>
>We don't have single clue what you are trying to say. Can you try to
>explain in another way perhaps.
>We just want to have as many suggestion as possible to how we can solve
>our problem.
>>

>
What I am telling you is that you running that application in the VS IDE
using VS's file based Web server/application server is NOT the same thing
as taking that project from the start, using an ASP.NET project type and
setting that project up to run directly against IIS on a development
machine.
>
Obviously, the two project types are not the same. On one hand, the
solution running against VS's Web file based server/application is not
blowing-up. On the other hand, the solution is blowing-up when running
against IIS.
>
Therefore, one must test the application in VS debug mode with the
application being a true ASP.NET solution to find out what is the cause of
the application termination which causes IIS to abort too.
>
You will most like have to convert the VS Web file based/application
server project over to a ASP.NET project that is using IIS to test the
project in debug mode to uncover what is going wrong, use Google to find
out how to convert the file Web based project type over to an ASP.NET
project type using IIS.
>
The information in the link is telling you the possible conditions of the
application abort, and it is obvious that the VS Web based file
server/application server could be more forgiving than that solution being
a ASP.NET solution tested and debugged against IIS on the development
machine.
>

http://msdn.microsoft.com/en-us/library/ms164911(VS.80).aspx

>
>
>

>>
>>
>"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
>news:uak8dzbOJ HA.4180@TK2MSFT NGP05.phx.gbl.. .

>>>
>>"Tony Johansson" <t.johansson@lo gica.comwrote in message
>>news:OaTXdibO JHA.4088@TK2MSF TNGP02.phx.gbl. ..
>>>
>>>Another thing that is of interest is that if we run the built-in
>>>applicatio n server in Visual Studio which exist by default we never get
>>>any kind of error.
>>>This is strange because when we run the built-in application server the
>>>asp will call the MFC dll but when we run it in this way we never ever
>>>get any kind of problem.
>>>
>>The VS file based Web server on the development machine is not IIS. At
>>the very least, the Web server file based solution should have been
>>converted to run against IIS on the development machine.
>>>
>>To develop a solution to run against the VS file based Web server on the
>>development machine, solely if that is what has happened here, and never
>>running it against IIS on the development machine is a no no.
>>>
>>http://msdn.microsoft.com/en-us/libr...11(VS.80).aspx
>>>

>>

>

[Mr. Arnold]

Re: Having great problem with an C# application


"Tony Johansson" <t.johansson@lo gica.comwrote in message
news:u8F1PCeOJH A.588@TK2MSFTNG P06.phx.gbl...

Hello!!
>
We have now a local IIS on our development computer.
We have not tested yet because we have to do some preparation before we
can test
if we get the same kind of problem when running a local IIS.
>
Most certain will we get the same kind of problem that we have on the
computer
where we run windows server 2003.
>
If we get the same kind of problem when running through the local IIS is
it in
any way possible to step in and debug the MFC dll that cause the problem ?
>
Our asp application project was created by using Open Website in VS.

If you have the source code for this MFC DLL you talk about, then you should
be able to set a project reference to the DLL's source code and debug it
within your ASP.NET project.