Lost Thread/Subprocess

[Tobias Bergmann]

Hello,

this is really a hardcore question for Microsoft professionals!

I have got a .NET 2.0 UserControl DLL.
When it is started it checks for a certain object that stores data and
communicates cyclically to a server. This object is a static variable
because in some applications the UserControl should be disposed and build up
later and the background data store object should remain meanwhile.

It works perfect so far.

But... When I embed the UserControl into a ASP.net web page I get trouble. I
can jump from a page showing the UserControl to another and back and the
data container object in the background still works in the background. But
when I then close the IE there is a system message about an exception on
accessing address XXX in process XXX.

I think the problem is: The background object still works even without the
calling object but when the IE is closed nobody tells the background object
that the hosting process was stopped. And so it suddendly acts within
non-allocated memory without a hosting process and that is what causes a
crash.

Can anybody follow me and has anybody advice for me?

Thanks a lot in advance!

 

[Gregory A. Beamer]

I think the problem is: The background object still works even without the
calling object but when the IE is closed nobody tells the background
object that the hosting process was stopped. And so it suddendly acts
within non-allocated memory without a hosting process and that is what
causes a crash.

The problem here is coding a user control as if it is partially a control
and partially a Singleton. You would be better served to move the static
bits to another object and use it as a Singleton (assuming it has
application wide scope). If, instead, you need it to act like a Singleton
per session, you need some more work on the model, but since you are closing
IE, I am not sure that is your issue.

A User Control is a UI element and should be used as a UI element. It is not
designed to hold session-wide or application-wide state, so don't set it up
that way or you will head for trouble. Separate out the other concerns, even
if they are only used in the context of the user control.

You can probably code something in the destructor of the control to cleanup
the static variables, but this is just a bandaid for a bad design.

--
Peace and Grace,
Greg

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

************************************************
| Think outside the box! |
************************************************

 

[Tobias Bergmann]

Hello Greg,

the UserControl itself is just a UI and the object that is static is just a
class/instance. This architecture was originally designed for a windows
forms application and it worked very well.
But then somebody had the idea to use it also within a web browser and it
also worked. Just the little aspect that it causes an address access
conflict when the IE is closed.

The funny thing is that the destructor of the data cache class in the
cackground is not called when the IE is closed so I can not release anything
and that is propably tthe reason for the crash. I guess the IE is a
different technology than pure .NET and so the static instance of data cache
is somewhere running in the IE process but this process takes no care of it.

That is why I decided to implement something like an close event of the own
process. This code within the corstructor of my data cache class looks like
that:

myProcess = Process.GetCurrentProcess();

myProcess.EnableRaisingEvents = true;

myProcess.Exited += new EventHandler(myProcess_Exited);


But the myProcess_Exited event is never called when the IE is closed. But I
can see that myProcess is realy the current hosting IE.
I have the strange feeling that the IE has a sophisticated process structure
and the GetCurrentProcess method just returns the handle to a certain part
of the IE and this is not the part that tells me that the IE is closed...

So I am still searching for a solution, even if you suggested to do a
complete re-design of the architecture what is impossible at the moment.

Thanks nevertheless
Tobias