First the circumstances that cause the crash.
I wrote a WinForms Control. It can be dragged into the designer and used like any other control. When it is used in projects that are not written using the designer, they build and execute just fine. The problem comes when it is open in the designer. It causes a crash any time anything changes the underlying code enough to cause the designer to refactor things. If I try to build a project that has the control in it, the IDE crashes. If I build the .dll containing the control and the control is open in another designer, the IDE crashes. If I try to close the designer window for the form that contains the control, the IDE crashes. In general, I can not do anything with the designer at all using my control without it eventually killing the IDE.
The things I have tried to fix the problem.
First thing I thought it was, was improper serialization of code, or improper dispose methods. I read a bit on all and made some changes that I hope would fix it, but the problem persists. The only things that cause code serialization in the designer are now display options, such as font, position, size, color, etc. The dispose method was also changed, so that its components are disposed of properly, etc. These things were already done to some extent but I went back and double/tripple checked them to make sure they were correct, and even made some small adjustments just in case. The end result is the same though, the IDE will crash.
The memory dump translated via WinDbg.exe.
FAULTING_IP:
+0
00000000
EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
FAULTING_THREAD: 00000d2c
BUGCHECK_STR: 80000003
DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
PROCESS_NAME: WindowsApplication4.vshost.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
MANAGED_STACK:
(TransitionMU)
0012F458 793D424E mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int64, Boolean)+0x2e
0012F470 793D4193 mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int32, Boolean)+0x23
0012F480 793D420E mscorlib_ni!System.Threading.WaitHandle.WaitOne()+0xa
0012F484 00D5059A WindowsApplication4_vshost!Microsoft.VisualStudio.HostingProcess.EntryPoint.Main()+0x2a
(TransitionUM)
LAST_CONTROL_TRANSFER: from 7c90e9ab to 7c90eb94
STACK_TEXT:
0012f148 7c90e9ab 7c8094f2 00000001 0012f174 ntdll!KiFastSystemCallRet
0012f14c 7c8094f2 00000001 0012f174 00000000 ntdll!ZwWaitForMultipleObjects+0xc
0012f1e8 79f8ead4 00000001 0012f438 00000001 kernel32!WaitForMultipleObjectsEx+0x12c
0012f250 79f17522 00000001 0012f438 00000001 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0x6f
0012f270 79f17493 00000001 0012f438 00000001 mscorwks!Thread::DoAppropriateAptStateWait+0x3c
0012f2f4 79f1732f 00000001 0012f438 00000001 mscorwks!Thread::DoAppropriateWaitWorker+0x144
0012f344 7a07b49c 00000001 0012f438 00000001 mscorwks!Thread::DoAppropriateWait+0x40
0012f448 793d424e 00000000 00000000 0012f4ac mscorwks!WaitHandleNative::CorWaitOneNative+0x14e
0012f490 79e88ee4 0012f560 00000000 0012f530 mscorlib_ni+0x31424e
0012f510 79e88e31 0012f560 00000000 0012f530 mscorwks!CallDescrWorkerWithHandler+0xa3
0012f650 79e88d19 00a17500 0012f72c 0012f6e0 mscorwks!MethodDesc::CallDescr+0x19c
0012f668 79e88cf6 00a17500 0012f72c 0012f6e0 mscorwks!MethodDesc::CallTargetWorker+0x20
0012f67c 79f084b0 0012f6e0 35d2bfe2 00000000 mscorwks!MethodDescCallSite::Call+0x18
0012f7e0 79f082a9 00a17498 00000001 0012f81c mscorwks!ClassLoader::RunMain+0x220
0012fa48 79f0817e 00000000 35d2b232 00000000 mscorwks!Assembly::ExecuteMainMethod+0xa6
0012ff18 79f07dc7 00400000 00000000 35d2b7ae mscorwks!SystemDomain::ExecuteMainMethod+0x398
0012ff68 79f05f61 00400000 35d2b776 00000000 mscorwks!ExecuteEXE+0x59
0012ffb0 79011b5f 0012f384 79e70000 0012fff0 mscorwks!_CorExeMain+0x11b
0012ffc0 7c816d4f 00000000 0012f384 7ffdf000 mscoree!_CorExeMain+0x2c
0012fff0 00000000 79011b2b 00000000 00000000 kernel32!BaseProcessStart+0x23
STACK_COMMAND: ~0s; .ecxr ; kb
FOLLOWUP_IP:
mscorlib_ni+31424e
793d424e 3d80000000 cmp eax,80h
SYMBOL_STACK_INDEX: 8
SYMBOL_NAME: mscorlib_ni+31424e
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: mscorlib_ni
IMAGE_NAME: mscorlib.ni.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 445b8d66
FAILURE_BUCKET_ID: 80000003_mscorlib_ni+31424e
BUCKET_ID: 80000003_mscorlib_ni+31424e
Followup: MachineOwner
--------
After looking at that for a while with some help, I have decided I do not really know what is going on. I first thought it may be something is not being correctly disposed of during garbage collection and an object is being referanced illegally, but I do no think that should cause the IDE to crash! I am not thinking that maybe it is a threading issue, but I am not sure about that.
Is there anyone out there who knows how the IDE works well enough to give me a good direction to look in, in order to fix this problem. I do not know where to start anymore. All the things I thought it was in the beginning seem to not be it.
And just as an asside, the crash does not occure on my machine or on my version of the IDE alone. It also occurs on other machines and has caused the profesional version of VS 2005 to crash also.
Thanks for any help.
Isaac
--

Control change causes IDE to crash.
PaulKotlyar
Your timers are not being disposed of stupid.
The moral to the story is, when you are writing a control, make sure you are putting all the components in the component container so it is cleaned up correctly when the control is diposed of.
Isaac
--