VS2008 si blocca quando passa alla modalità di progettazione su vasta soluzione

Question

Questo sta accadendo su diversi sviluppatori macchine che hanno appena ricevuto. Noi abbiamo una grande soluzione, 70+ progetti. Se si apre qualsiasi forma, anche un nuovo modulo vuoto, in modalità di progettazione, VS si blocca la maggior parte del tempo. Creazione di una soluzione più piccola con alcuni degli stessi progetti non causa il problema. E non tutti gli sviluppatori stanno avendo esso. Abbiamo VS2008 SP1, Windows XP, ed è VB.net WinForms. Ho cercato google, ma tutti i crash VS sembra di coinvolgere i componenti aggiuntivi o WPF. Essi non sono nuove macchine, ma sono stati nuovamente ripreso dal reparto IT, immagino che sono tutti copiati dalla stessa immagine.

Eccezione:

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)

A proposito: se vi state chiedendo come ottenere l'eccezione da Visual Studio. Ho aperto 2 copie di VS. Ho attaccato il primo al secondo in Strumenti \ Attacchi il processo. Poi ha aperto la soluzione nella seconda e si è schiantato esso.

Answer 1

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.

Answer 2

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.