Strange exception in mscorlib with CultureInfo using code converted to .NET 2.0

Hi,

I recently converted an application that was originally developed in VS 2003 and .NET 1.1 to .NET 2.0 using VS 2005. I've faced many problems with the conversion but was able to resolve all of them except this one. I hope this is the right forum to post this question in. If it's not, please direct me to the appropriate location.

This problem is not repeatable because the failure is inconsistent in where

it appears. Sometimes the error happens in one place, and sometimes it doesn't,

and then happens a few lines later - with the exact same settings, situation,

etc.

This is the code that generally causes the problem:

private CultureInfo DeserializeCultureInfo(byte[] cultureData)

{
MemoryStream stm = new MemoryStream(cultureData);


BinaryFormatter bf = new BinaryFormatter();
CultureInfo ci = null;

try
{
ci = (CultureInfo)bf.Deserialize(stm);


}
catch
{
}

stm.Close();
return(ci);
}

The non-repeatability comes from the fact that sometimes the error

(NullReferenceException) occurs on the
ci=(CultureInfo)bf.Deserialize(stm);

line,

and sometimes it occurs upon returning from the function on the

CultureInfo cultureInfo = DeserializeCultureInfo(cultureData); line

and sometimes it happens on some random line that is completely inoccuous

somewhere in that area - for instance the "{" line after the "catch" statement -

as if the error is in another thread, and while the debugger moves along, the

mscorlib code crashes a little bit later.

The byte array cultureData has been viewed during Debug and does not appear

to be out of the ordinary in any way.

source: "mscorlib"

Stack trace:
at

System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage

msg, IMessageSink replySink)
at

System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object

o)
at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object

state)
at System.Threading.ExecutionContext.Run(ExecutionContext

executionContext, ContextCallback callback, Object state)
at

System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

[2309 byte] By [npinski] at [2007-12-23]
# 1

Dude, I'm experiencing the same stupid issue although it's in a piece of code that works with an sql command object. It normally happens on a line that calls SqlCommandBuilder.DeriveParametes(sqlCmd), but sometimes i happens on the line after it, or about 10 lines further down. I end up with the same NullReferenceException and stack trace as what you posted above. I also just upgraded the proj from 1.1 to 2.0.

Did you make any progress on the issue? I'll let you know if I find anything.

MichaelDaly at 2007-8-31 > top of Msdn Tech,.NET Development,.NET Remoting and Runtime Serialization...
# 2
No, no progress...but this project is currently in a bit of a standstill, so there hasn't been any work done with it for a little while.
npinski at 2007-8-31 > top of Msdn Tech,.NET Development,.NET Remoting and Runtime Serialization...
# 3

Hi all,

I am also facing this strange issue.

We have an ASP.NET 2.0 application (migrated from 1.1) running on Win 2003 Server (IIS 6.0). There are many instances of this application running on different application pool for each of our client.

All the time it works fine but sometimes it just dies throwing exceptions from mscorlib like IndexOutOfRangeException etc. and we have to recycle/restart that specific pool. It seems when it dies, it's not able to instantiate an object because mainly it happens in new().

Any guesses?

Best,

Praveen

Pravs at 2007-8-31 > top of Msdn Tech,.NET Development,.NET Remoting and Runtime Serialization...
# 4
I found where the problem was being caused. The problem was actually being caused by some code that was called beforehand through a delegate.begininvoke. I was using begininvoke to asynchronously call a method that has the OneWay attribute on it. Once I remove the OneWay attribute the crash goes away. I found one other person on the web experiencing the same issue and I'm thinking that it was also no coincidence that he upgraded his project to 2.0 from 1.1. I'm thinking of going through the pain of creating a new empty 2.0 project and readding all of the files manually to see if that fixes it.
MichaelDaly at 2007-8-31 > top of Msdn Tech,.NET Development,.NET Remoting and Runtime Serialization...

.NET Development

Site Classified