Yossi Dahan [BizTalk]


Saturday, February 07, 2009

VS crashes? check your colour depth setting!

Over the last few months we've been seeing quite a few Visual Studio crashes when working with the orchestration designer.

The scenarios vary slightly between machines - some would crash on build, others simply when opening an orchestration in the designer; some would crash very frequently, some only sporadically; some would crash even when opening the solution immediately after a reboot, others would work fine for a while and then crash; the bottom line was that we were having lots of crashes, and we were losing on developer productivity and gaining tons of frustration.

Because the problems did not happen in a very consistent manner, and because there were different manifestations we simply had no clue what might be the cause; we've talked to a few people and searched the web; we’ve followed almost every tip we've received (make sure no documents are open when you build, collapse all shapes in an orchestration before saving it, etc.); some seem to have helped a little bit, but the crashes kept happening.

Sometimes Visual Studio would show an error on the screen – something like -


But in other times, it simply crashed without a warning.

Eventually we’ve contacted Microsoft support, and analysing dumps we’ve created they have found the following error -

Exception type: System.InvalidOperationException
Message: BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress.
StackTrace (generated):
System_Drawing_ni!System.Drawing.BufferedGraphicsContext.AllocBufferInTempManager(System.Drawing.Graphics, IntPtr, System.Drawing.Rectangle)
System_Drawing_ni!System.Drawing.BufferedGraphicsContext.Allocate(IntPtr, System.Drawing.Rectangle)
System_Windows_Forms_ni!System.Windows.Forms.Control.WmPaint(System.Windows.Forms.Message ByRef)
System_Windows_Forms_ni!System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
System_Windows_Forms_ni!System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr, Int32, IntPtr, IntPtr)


From this it was clear that the issue is related to GDI+ when VS redraws the orchestration and MS have confirmed they have seen this issue elsewhere (outside the BizTalk realm), but we were told that this problem was “aggravated by the fact that BizTalk creates very large device-independent bitmaps and uses the same colour depth than the desktop.”

Unfortunately, according to Microsoft, there are many contributing factors to this issue, and it is virtually impossible to isolate the cause(s) in our case, but two recommendations were made -

  • Use a video card with more memory

  • Lower colour depth setting from 32 bit to 16 bit in the display settings in windows

  • Split large orchestrations to smaller ones

That last recommendation would have been our last resort – not only it would require a significant re-factor-re-test effort as our solution is quite  big, it would seriously decrease our already too long deployment time.

We were quite happy to follow the first recommendation, but obviously trying the second one was pretty effortless we went with that first and what do you know – it worked!

Machines which have changed the colour depth setting to 16 bit stopped having those frequent crashes;

It must be said we’re still experiencing some crashes, so there are other issues as well, but these are more specific, and are another story altogether, one to be told once the end is known!

Labels: ,

Monday, August 11, 2008

Visual Studio 2008 SP1 and .net framework 3.5 SP1 released!

Both have been officially released today and can be downloaded here.

It is worth mentioning though that this time (although not the first time, and certainly not the last time) this "service pack" contains significantly more than just fixes and improvements - there's quite a few significant enhancements and new features in it.

Amongst others that includes the long awaited entity framework and the ADO.net Data Service. see more details here


Sunday, July 06, 2008

Where is that orchestration?

I like visual designers. what I don't like is visual designers that try to protect developers from themselves; they always seem to go just one or two steps too far.

I find myself (and others, I believe) complain fairly frequently about the orchestration designer not letting us do this or that...and while in many cases it all makes sense (you really can't, or shouldn't be doing that), being over protected can cause a lot of confusion and waste precious time. here as example of something that happened to me a couple of weeks ago -

I was configuring a start shape in one of my processes, and when I tried to select the orchestration I wanted to start, it simply did not appear on the list of available orchestrations.

It took me a while - I rebuilt the assembly with the started orchestration and refreshed the assembly with the starting one - twice, but could not get it to appear. I've tried everything - including resorting to restarting visual studio -but could not see my process.

Only when I checked carefully the parameters requested by the started orchestration did I spot the problem - the orchestration had a 'ref' parameter.

Apparently orchestrations that have out or ref (I suspect they are pretty much the same in BizTalk) parameters do not appear on the list of processes in a start orchestration shape.

This makes sense really, as the start shape is asynchronous there's no way to use ref/out parameters with it. I just think a better design decision would have been to flag such selection as an error (at design and compile time) and not simply hide the irrelevant orchestrations.

This way it is immediately clear why I can't select the orchestration I planned to, I don't have to figure all of this out every time.

Labels: , ,

Thursday, August 02, 2007

Editing Xmls with intellisense in Visual Studio

Am I the last person in the world to realise that? hopefully not!...

...but I've just realised today that if you edit an xml file in visual studio and you have the schema of the xml you're editing open in another tab it will recognise it (as soon as you type the root node and namespace) and will provide intellisense.

I knew you could tell it to use a schema, but I did not realise it will automatically include opened documents. brilliant feature!

Labels: , ,