VS2008 crashes when switched to design mode on very large solution

This is happening on several developers machines that they just received. We have a very large solution, 70+ projects. If you open any form, even a new blank form, in design mode, VS Crashes most of the time. Creating a smaller solution with some of the same projects does not cause the issue. And not all developers are having it. We have vs2008 SP1, Windows XP, 开发者_JS百科and it's VB.net Winforms. I've searched google, but all the VS crashes seem to involve addins or WPF. They are not new machines but have been re imaged by the IT dept, I imagine they are all copied from the same image.

Exception:

System.AccessViolationException was unhandled
  Message="Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
  Source="System.Drawing"
  StackTrace:
       at System.Drawing.SafeNativeMethods.Gdip.GdipFillRectangleI(HandleRef graphics, HandleRef brush, Int32 x, Int32 y, Int32 width, Int32 height)

       at System.Drawing.Graphics.FillRectangle(Brush brush, Int32 x, Int32 y, Int32 width, Int32 height)

       at System.Drawing.Graphics.FillRectangle(Brush brush, Rectangle rect)

       at ystem.Windows.Forms.Design.Behavior.SelectionBorderGlyph.Paint(PaintEventArgs pe)

       at     
System.Windows.Forms.Design.Behavior.BehaviorService.PropagatePaint(PaintEventArgs pe)

       at System.Windows.Forms.Design.Behavior.BehaviorService.AdornerWindow.WndProc(Message& m)


       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)

       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, 
IntPtr wparam, IntPtr lparam)

FYI: if you're wondering how to get the exception from visual studio. I opened 2 copies of VS. I attached the first one to the second one under Tools\Attach Process. Then opened the solution in the second and crashed it.

---

This looks like a bug in GDI+. I'm guessing it doesn't handle running out of resources real well. Windows gives a process a quota on things like handles, windows and GDI resources like pens and brushes. When it exceeds 10000 of them, it refuses to give anymore, assuming that a leak in the program is the problem.

You can see this with Taskmgr.exe, Processes tab. View + Select Columns, tick Handles, USER objects and GDI objects. Once one of these get close to the quota, all manner of misery starts to happen. Usually painting oddities btw. But certainly code can crash when it doesn't check that the API call returns NULL. All too common in unmanaged code.

GDI+ was much improved for Vista, devs really shouldn't be running XP anymore these days. Win7 is quite nice. Also the only real way to learn to deal with UAC and session 0 isolation.

As a possible workaround, ask at superuser.com how to increase the default process quota. Its somewhere in the registry.

---

Looks like it's video driver related, even though the machines are different models with different video. All the effected machines are working with the video driver disabled in device manager. Installing the latest video driver has fixed all but one of them. The one that is not fixed is now working if you slide the hardware acceleration slider almost to none. The slider trick did not work before which was why I hadn't considered video as the problem. We probably will live w/o the hardware acceleration on that machine.

We had some machines come in a year ago that would not show the dataset designer, and we had to turn down the hardware acceleration on those to get them to show. So several of our machines are running that way already.