Question

I create a new blank form and the tried to switch to design mode and the ide locks up and uses 100% of one of my CPUs. I have to forcibly kill it to get back into a workable ide. Everything seems fine when viewing the source code. I tried this both in existing project (that works on someone else’s machine), and a brand new solution, both with the same outcome. I’m working on a WinXP pro box with all updates installed.

Performing the actions recommended below (attaching a debugger and pausing execution) shows that it is stuck here:

[Managed to Native Transition]  

System.Drawing.dll!System.Drawing.Graphics.DrawRectangle(System.Drawing.Pen pen, int x, int y, int width, int height) + 0x3d bytes
System.Drawing.dll!System.Drawing.Graphics.DrawRectangle(System.Drawing.Pen pen, System.Drawing.Rectangle rect) + 0x14 bytes
System.Design.dll!System.Windows.Forms.Design.PanelDesigner.DrawBorder(System.Drawing.Graphics graphics) + 0x97 bytes
System.Design.dll!System.Windows.Forms.Design.PanelDesigner.OnPaintAdornments(System.Windows.Forms.PaintEventArgs pe = {ClipRectangle = {System.Drawing.Rectangle}}) + 0x50 bytes
System.Design.dll!System.Windows.Forms.Design.ControlDesigner.WndProc(ref System.Windows.Forms.Message m) + 0xd1e bytes
System.Design.dll!System.Windows.Forms.Design.ScrollableControlDesigner.WndProc(ref System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x12 bytes
System.Design.dll!System.Windows.Forms.Design.ControlDesigner.DesignerWindowTarget.OnMessage(ref System.Windows.Forms.Message m) + 0x55 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x31 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 15, System.IntPtr wparam, System.IntPtr lparam) + 0x57 bytes

Answer 1

The most likely cause of the hang is a custom control which enters an infinite loop during it’s initialization is being displayed in the design form. The easiest way to check this is to let Visual Studio freeze, then use another instance of Visual Studio to attach to the process. Break the execution and it should reveal the cause of the hang on the call stack.