NullReferenceException in UnsafeNativeMethods.CreateWindowEx

[Tester]

Hi all,

I have the following situation. I create AppDomains on demand to host
winform based controls from C++ host. I'm using .NET 1.1.

I tried to do AppDomain.Unload from background thread to free up the main
GUI thread and make it more responsive.

When I try this, I get the exception, listed below, always on the 3rd
AppDomain and control creation.

I tried getting SystemEvents through reflection and calling Shutdown
manually. This delays the problem. It almost doesn't happen, but still
re-appears
sometimes.

This doesn't reproduce in .NET 2.0 alpha.

Is there any way I can work around this bug/limitation?

I also would like to know what is being null inside the
UnsafeNativeMethods.CreateWindowEx or under what conditions.
Maybe I can work around the problem.

Thank you in advance for any help on this

Exception trace:
------------------
System.Reflection.TargetInvocationException: Exception has been thrown by
the target of an invocation. ---> System.TypeInitializationException: The
type initializer for "System.Drawing.SafeNativeMethods" threw an
exception. ---> System.NullReferenceException: Object reference not set to
an instance of an object.

at Microsoft.Win32.UnsafeNativeMethods.CreateWindowEx(Int32 exStyle,
String lpszClassName, String lpszWindowName, Int32 style, Int32 x, Int32 y,
Int32 width, Int32 height, HandleRef hWndParent, HandleRef hMenu, HandleRef
hInst, Object pvParam)

at Microsoft.Win32.SystemEvents.CreateBroadcastWindow()

at Microsoft.Win32.SystemEvents.Initialize()

at Microsoft.Win32.SystemEvents.EnsureSystemEvents(Boolean requireHandle,
Boolean throwOnRefusal)

at Microsoft.Win32.SystemEvents.AddEventHandler(Int32 key, Delegate
value)

at Microsoft.Win32.SystemEvents.add_EventsThreadShutdown(EventHandler
value)

at System.Drawing.SafeNativeMethods.Initialize()

at System.Drawing.SafeNativeMethods..cctor()

--- End of inner exception stack trace ---

at System.Drawing.SafeNativeMethods.get_ThreadData()

at System.Drawing.SystemBrushes.FromSystemColor(Color c)

at System.Drawing.SystemBrushes.get_Window()

at
System.Windows.Forms.DataGridTableStyle.get_DefaultAlternatingBackBrush()

at System.Windows.Forms.DataGridTableStyle..ctor(Boolean
isDefaultTableStyle)

at System.Windows.Forms.DataGrid..ctor()

at DotNetControls.MainControl.InitializeComponent()

at DotNetControls.MainControl..ctor()

--- End of inner exception stack trace ---


Server stack trace:
at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly)

at System.Activator.CreateInstance(Type type, Boolean nonPublic)

at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder
binder, Object[] args, CultureInfo culture, Object[] activationAttributes)

at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr,
Binder binder, Object[] args, CultureInfo culture, Object[]
activationAttributes)

at System.Activator.CreateInstance(String assemblyName, String typeName,
Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args,
CultureInfo culture, Object[] activationAttributes, Evidence securityInfo,
StackCrawlMark& stackMark)

at System.Activator.CreateInstance(String assemblyName, String typeName)

at System.AppDomain.CreateInstance(String assemblyName, String typeName)

at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String
typeName)

at
System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(Met
hodBase mb, Object[] args, Object server, Int32 methodPtr, Boolean
fExecuteInContext, Object[]& outArgs)

at
System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessa
ge msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessage retMsg)

at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 type)

at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String
typeName)

at Adapter.CreateApp() in ...

 

[John Eikanger [MSFT]]

Hi, Leon

I spoke to one of the C++ tech leads, and he suggested pointing you at the
ThreadMarshal sample in the SDK. You can find it at C:\Program
Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\QuickStart\howto\samples\winforms\threadmarshal.

It's unclear from your description whether you are using Managed C++.
Could you clarify?

I've requested further assistance on this issue, so please stand by for
more questions.

Thank you for choosing the MSDN Managed Newsgroups,

John Eikanger
Microsoft Developer Support

This posting is provided “AS IS” with no warranties, and confers no rights.
--------------------
| From: "Tester" <[email protected]>
| Subject: NullReferenceException in UnsafeNativeMethods.CreateWindowEx
| Date: Tue, 22 Jun 2004 21:13:45 -0400
| X-Tomcat-NG: microsoft.public.dotnet.framework.windowsforms
|
| Hi all,
|
| I have the following situation. I create AppDomains on demand to host
| winform based controls from C++ host. I'm using .NET 1.1.
|
| I tried to do AppDomain.Unload from background thread to free up the main
| GUI thread and make it more responsive.
|
| When I try this, I get the exception, listed below, always on the 3rd
| AppDomain and control creation.
|
| I tried getting SystemEvents through reflection and calling Shutdown
| manually. This delays the problem. It almost doesn't happen, but still
| re-appears
| sometimes.
|
| This doesn't reproduce in .NET 2.0 alpha.
|
| Is there any way I can work around this bug/limitation?
|
| I also would like to know what is being null inside the
| UnsafeNativeMethods.CreateWindowEx or under what conditions.
| Maybe I can work around the problem.
|
| Thank you in advance for any help on this
|
| Exception trace:
| ------------------
| System.Reflection.TargetInvocationException: Exception has been thrown by
| the target of an invocation. ---> System.TypeInitializationException: The
| type initializer for "System.Drawing.SafeNativeMethods" threw an
| exception. ---> System.NullReferenceException: Object reference not set to
| an instance of an object.
|
| at Microsoft.Win32.UnsafeNativeMethods.CreateWindowEx(Int32 exStyle,
| String lpszClassName, String lpszWindowName, Int32 style, Int32 x, Int32
y,
| Int32 width, Int32 height, HandleRef hWndParent, HandleRef hMenu,
HandleRef
| hInst, Object pvParam)
|
| at Microsoft.Win32.SystemEvents.CreateBroadcastWindow()
|
| at Microsoft.Win32.SystemEvents.Initialize()
|
| at Microsoft.Win32.SystemEvents.EnsureSystemEvents(Boolean
requireHandle,
| Boolean throwOnRefusal)
|
| at Microsoft.Win32.SystemEvents.AddEventHandler(Int32 key, Delegate
| value)
|
| at Microsoft.Win32.SystemEvents.add_EventsThreadShutdown(EventHandler
| value)
|
| at System.Drawing.SafeNativeMethods.Initialize()
|
| at System.Drawing.SafeNativeMethods..cctor()
|
| --- End of inner exception stack trace ---
|
| at System.Drawing.SafeNativeMethods.get_ThreadData()
|
| at System.Drawing.SystemBrushes.FromSystemColor(Color c)
|
| at System.Drawing.SystemBrushes.get_Window()
|
| at
| System.Windows.Forms.DataGridTableStyle.get_DefaultAlternatingBackBrush()
|
| at System.Windows.Forms.DataGridTableStyle..ctor(Boolean
| isDefaultTableStyle)
|
| at System.Windows.Forms.DataGrid..ctor()
|
| at DotNetControls.MainControl.InitializeComponent()
|
| at DotNetControls.MainControl..ctor()
|
| --- End of inner exception stack trace ---
|
|
| Server stack trace:
| at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly)
|
| at System.Activator.CreateInstance(Type type, Boolean nonPublic)
|
| at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr,
Binder
| binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
|
| at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr,
| Binder binder, Object[] args, CultureInfo culture, Object[]
| activationAttributes)
|
| at System.Activator.CreateInstance(String assemblyName, String
typeName,
| Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[]
args,
| CultureInfo culture, Object[] activationAttributes, Evidence securityInfo,
| StackCrawlMark& stackMark)
|
| at System.Activator.CreateInstance(String assemblyName, String
typeName)
|
| at System.AppDomain.CreateInstance(String assemblyName, String
typeName)
|
| at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String
| typeName)
|
| at
|
System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(Met
| hodBase mb, Object[] args, Object server, Int32 methodPtr, Boolean
| fExecuteInContext, Object[]& outArgs)
|
| at
|
System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessa
| ge msg, Int32 methodPtr, Boolean fExecuteInContext)
|
| Exception rethrown at [0]:
| at
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
| reqMsg, IMessage retMsg)
|
| at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
| msgData, Int32 type)
|
| at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String
| typeName)
|
| at Adapter.CreateApp() in ...
|
|
|

 

[Leon Finker]

Hi John,

I'm using unmanaged C++ host. But I think exact same thing will happen in
pure .NET application. I'll try to verify this.

The C++ host just starts CLR, creates type and hands over all control of the
program to .NET side. .NET side creates AppDomain and hosts WinForm controls
in it.

The problem seems to be Unloading AppDomain from thread that didn't create
the WinForm controls. This is the only case when CreateWindowEx causes
NullReferenceException for some reason always on 3rd or 4th try.

There is no problem if I Unload AppDomain from thread that created it.

But I would like to queue Unloads to background thread due to responsiveness
requirements of the application. I also Dispose() of all WinForm controls in
that AppDomain
before doing this (including the ParkingWindow).

Thank you for looking into this

Hi, Leon

I spoke to one of the C++ tech leads, and he suggested pointing you at the
ThreadMarshal sample in the SDK. You can find it at C:\Program
Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\QuickStart\howto\samples\winforms\threadmarshal.

It's unclear from your description whether you are using Managed C++.
Could you clarify?

I've requested further assistance on this issue, so please stand by for
more questions.

Thank you for choosing the MSDN Managed Newsgroups,

John Eikanger
Microsoft Developer Support

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
| From: "Tester" <[email protected]>
| Subject: NullReferenceException in UnsafeNativeMethods.CreateWindowEx
| Date: Tue, 22 Jun 2004 21:13:45 -0400
| X-Tomcat-NG: microsoft.public.dotnet.framework.windowsforms
|
| Hi all,
|
| I have the following situation. I create AppDomains on demand to host
| winform based controls from C++ host. I'm using .NET 1.1.
|
| I tried to do AppDomain.Unload from background thread to free up the main
| GUI thread and make it more responsive.
|
| When I try this, I get the exception, listed below, always on the 3rd
| AppDomain and control creation.
|
| I tried getting SystemEvents through reflection and calling Shutdown
| manually. This delays the problem. It almost doesn't happen, but still
| re-appears
| sometimes.
|
| This doesn't reproduce in .NET 2.0 alpha.
|
| Is there any way I can work around this bug/limitation?
|
| I also would like to know what is being null inside the
| UnsafeNativeMethods.CreateWindowEx or under what conditions.
| Maybe I can work around the problem.
|
| Thank you in advance for any help on this
|
| Exception trace:
| ------------------
| System.Reflection.TargetInvocationException: Exception has been thrown by
| the target of an invocation. ---> System.TypeInitializationException: The
| type initializer for "System.Drawing.SafeNativeMethods" threw an
| exception. ---> System.NullReferenceException: Object reference not set to
| an instance of an object.
|
| at Microsoft.Win32.UnsafeNativeMethods.CreateWindowEx(Int32 exStyle,
| String lpszClassName, String lpszWindowName, Int32 style, Int32 x, Int32
y,
| Int32 width, Int32 height, HandleRef hWndParent, HandleRef hMenu,
HandleRef
| hInst, Object pvParam)
|
| at Microsoft.Win32.SystemEvents.CreateBroadcastWindow()
|
| at Microsoft.Win32.SystemEvents.Initialize()
|
| at Microsoft.Win32.SystemEvents.EnsureSystemEvents(Boolean
requireHandle,
| Boolean throwOnRefusal)
|
| at Microsoft.Win32.SystemEvents.AddEventHandler(Int32 key, Delegate
| value)
|
| at Microsoft.Win32.SystemEvents.add_EventsThreadShutdown(EventHandler
| value)
|
| at System.Drawing.SafeNativeMethods.Initialize()
|
| at System.Drawing.SafeNativeMethods..cctor()
|
| --- End of inner exception stack trace ---
|
| at System.Drawing.SafeNativeMethods.get_ThreadData()
|
| at System.Drawing.SystemBrushes.FromSystemColor(Color c)
|
| at System.Drawing.SystemBrushes.get_Window()
|
| at
| System.Windows.Forms.DataGridTableStyle.get_DefaultAlternatingBackBrush()
|
| at System.Windows.Forms.DataGridTableStyle..ctor(Boolean
| isDefaultTableStyle)
|
| at System.Windows.Forms.DataGrid..ctor()
|
| at DotNetControls.MainControl.InitializeComponent()
|
| at DotNetControls.MainControl..ctor()
|
| --- End of inner exception stack trace ---
|
|
| Server stack trace:
| at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly)
|
| at System.Activator.CreateInstance(Type type, Boolean nonPublic)
|
| at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr,
Binder
| binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
|
| at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr,
| Binder binder, Object[] args, CultureInfo culture, Object[]
| activationAttributes)
|
| at System.Activator.CreateInstance(String assemblyName, String
typeName,
| Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[]
args,
| CultureInfo culture, Object[] activationAttributes, Evidence securityInfo,
| StackCrawlMark& stackMark)
|
| at System.Activator.CreateInstance(String assemblyName, String
typeName)
|
| at System.AppDomain.CreateInstance(String assemblyName, String
typeName)
|
| at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String
| typeName)
|
| at
|
System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(Met
| hodBase mb, Object[] args, Object server, Int32 methodPtr, Boolean
| fExecuteInContext, Object[]& outArgs)
|
| at
|
System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessa
| ge msg, Int32 methodPtr, Boolean fExecuteInContext)
|
| Exception rethrown at [0]:
| at
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
| reqMsg, IMessage retMsg)
|
| at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
| msgData, Int32 type)
|
| at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String
| typeName)
|
| at Adapter.CreateApp() in ...
|
|
|

 

[Ying-Shen Yu[MSFT]]

Hi Leon,

From your description, it seems the NullReferenceException was actually
happended in the unmanaged part inside the CreateWindowEx API, you may try
catching the "Access violation" Win32 exception in debugger and see if we
could get more information from the stack.

Due to the complexity of this issue, further investigation on this issue
may need more debugging and analyzing some dump ,which is far out of what
we can help in newsgroup. You may contact our Phone service for better
assistance.

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.

 

[Leon Finker]

Hi,

Just to clarify, the "Access Violation" happens in:
Microsoft.Win32.UnsafeNativeMethods.CreateWindowEx

Here is the call stack when debugging from C++ side:

001b3a3e()

user32.dll!_InternalCallWinProc@20() + 0x1b
user32.dll!_UserCallWinProcCheckWow@32() + 0x6e7d
user32.dll!_DispatchClientMessage@20() + 0x4d
user32.dll!___fnINLPCREATESTRUCT@4() + 0x5f
ntdll.dll!_KiUserCallbackDispatcher@12() + 0x13

Here is the callstack when debugging from .NET side:
system.dll!Microsoft.Win32.SystemEvents.CreateBroadcastWindow() + 0x233
bytes
system.dll!Microsoft.Win32.SystemEvents.Initialize() + 0x5e bytes
system.dll!Microsoft.Win32.SystemEvents.EnsureSystemEvents(bool
requireHandle = false, bool throwOnRefusal = false) + 0xda bytes
system.dll!Microsoft.Win32.SystemEvents.AddEventHandler(int key = 11,
System.Delegate value = {System.EventHandler}) + 0x77 bytes

system.dll!Microsoft.Win32.SystemEvents.add_EventsThreadShutdown(System.Even
tHandler value = {System.EventHandler}) + 0x14 bytes
system.drawing.dll!System.Drawing.SafeNativeMethods.Initialize() + 0x19d
bytes
system.drawing.dll!System.Drawing.SafeNativeMethods..cctor() + 0xca bytes
system.drawing.dll!System.Drawing.SafeNativeMethods.get_ThreadData() +
0x13 bytes

system.drawing.dll!System.Drawing.SystemBrushes.FromSystemColor(System.Drawi
ng.Color c = {RGB=0x0}) + 0x96 bytes
system.drawing.dll!System.Drawing.SystemBrushes.get_Window() + 0x29 bytes

system.windows.forms.dll!System.Windows.Forms.DataGridTableStyle.get_Default
AlternatingBackBrush() + 0xa bytes

system.windows.forms.dll!System.Windows.Forms.DataGridTableStyle.DataGridTab
leStyle(bool isDefaultTableStyle = true) + 0x88 bytes
system.windows.forms.dll!System.Windows.Forms.DataGrid.DataGrid() + 0x33
bytes

dotnetcontrols.dll!DotNetControls.MainControl.InitializeComponent() Line

67 + 0x14 bytes C#

Hi Leon,

From your description, it seems the NullReferenceException was actually
happended in the unmanaged part inside the CreateWindowEx API, you may try
catching the "Access violation" Win32 exception in debugger and see if we
could get more information from the stack.

Due to the complexity of this issue, further investigation on this issue
may need more debugging and analyzing some dump ,which is far out of what
we can help in newsgroup. You may contact our Phone service for better
assistance.

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.

 

[Ying-Shen Yu[MSFT]]

Hi Leon,

I discussed with a senior engineer about this call stack, we suspect that
this issue was caused by a heap corruption happened sometimes before.You
may try enabling the pageheap.exe to help troublshooting this issue, it
will enable the verification layer in ntdll.dll to check the heap
allocation and de-allocation and access.
Hopefully you could get more precise call stack.

This KB article will provides you detail information on how to use
pageheap.

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q286470

You may need to contact our Phone Service to get more help on this issue.

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.

 

[Leon Finker]

Hi,

I have reproduced the problem in pure .NET winform and console simple app
in 2 different scenarios.
If there is a heap corruption, it's in .NET. But it's unlikely there is a
heap corruption and I tried pageheap. It didn't turn up anything useful. I
can send the repro project

 

[Ying-Shen Yu[MSFT]]

Hi Leon,

Please send me your repro project, I'll do some research on it to get more
information about this exception.
Thanks!
Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.

 

[Ying-Shen Yu[MSFT]]

Hi Leon,

I did some research on the repro sample,

To my understanding, the major difference after adding the
ShutdownSysEventsThread method is
the thread context when you destroy the BroadCastWindow.

In original repro sample, the Shutdown method will be called when the
AppDomain unloading, the execution thread is in the new thread you created.
As we know the underlying window handle has thread affinity, so we should
not create a window on one thread and destroy it on another, it will cause
trouble in user32. That's probably the cause of this issue.

If you add a call to ShutdownSysEventsThread method in the ctor of the
Proxy class,
the underlying BroadCastWindow is destroyed in this call, since the code
is executed in the main thread, it should work fine. However since the
BroadcastWindow is destroyed too early, I'm not sure if it will cause
trouble to the functionality of the controls later.

Hope it helps.

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.

 

[Leon Finker]

Hmm I didn't know on which thread BoradCastWindow was created.
Thank you for pointing this out. I'll try and find the right place to call
SystemEvents.Shutdown.
I'll check on which thread it is by using GetWindowThreadProcessId.

I'll see if destroying BroadcastWindow causes any trouble for the Controls.

Thank you for clarifying this

 

[Leon Finker]

BroadCastWindow is created/owned by different thread, and I can't really
execute code there easily. My real case is more like the second repro
sample.

Hmm I didn't know on which thread BoradCastWindow was created.
Thank you for pointing this out. I'll try and find the right place to call
SystemEvents.Shutdown.
I'll check on which thread it is by using GetWindowThreadProcessId.

I'll see if destroying BroadcastWindow causes any trouble for the Controls.

Thank you for clarifying this

Hi Leon,

I did some research on the repro sample,

To my understanding, the major difference after adding the
ShutdownSysEventsThread method is
the thread context when you destroy the BroadCastWindow.

In original repro sample, the Shutdown method will be called when the
AppDomain unloading, the execution thread is in the new thread you created.
As we know the underlying window handle has thread affinity, so we should
not create a window on one thread and destroy it on another, it will cause
trouble in user32. That's probably the cause of this issue.

If you add a call to ShutdownSysEventsThread method in the ctor of the
Proxy class,
the underlying BroadCastWindow is destroyed in this call, since the code
is executed in the main thread, it should work fine. However since the
BroadcastWindow is destroyed too early, I'm not sure if it will cause
trouble to the functionality of the controls later.

Hope it helps.

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.

 

[Ying-Shen Yu[MSFT]]

Hi Leon,

I haven't thought of a possible way to workaround this issue,
Why you need create and unload the AppDomain?
And is it possible to create the AppDomain on a new thread and unload in
that thread?

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.

 

[Leon Finker]

This is the requirement of a real world application. It has to be a loader
for winform apps. Each app is served on it's own thread and by its own
AppDomain. When main window of the app closes, thread is exited and
AppDomain unloaded. There are advantages to this including applying runtime
only CAS policies and many others that are needed for the project.

It might be possible to create new thread and then create AppDomain on it,
will make for an ugly design I think, but if it helps...Application.Run has
to run inside the AppDomain context for winforms to work properly, but it's
doable.

What will be the advantage of creating AppDomain on the thread itself?

I took the reverse approach. I created an AppDomain, and the thread is
created and started while executing in the AppDoman context.
This way, when AppDomain unloads, and if thread didn't exit nicely after
some given time, AppDomain.Unload will try to Abort it.

Thank you for your help

 

[Leon Finker]

Actually in real project I'm calling Shutdown on the thread that owns the
BroadCastWindow. I'm calling Shutdown at the end of the secondary Thread.
All WinForm related windows are created on that thread. So assuming it's ok
to call Shutdown, then it should be fine.

Thank you for point this out

This is the requirement of a real world application. It has to be a loader
for winform apps. Each app is served on it's own thread and by its own
AppDomain. When main window of the app closes, thread is exited and
AppDomain unloaded. There are advantages to this including applying runtime
only CAS policies and many others that are needed for the project.

It might be possible to create new thread and then create AppDomain on it,
will make for an ugly design I think, but if it helps...Application.Run has
to run inside the AppDomain context for winforms to work properly, but it's
doable.

What will be the advantage of creating AppDomain on the thread itself?

I took the reverse approach. I created an AppDomain, and the thread is
created and started while executing in the AppDoman context.
This way, when AppDomain unloads, and if thread didn't exit nicely after
some given time, AppDomain.Unload will try to Abort it.

Thank you for your help

Hi Leon,

I haven't thought of a possible way to workaround this issue,
Why you need create and unload the AppDomain?
And is it possible to create the AppDomain on a new thread and unload in
that thread?

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.