.NET (306) administrative (42) Ajax (42) AngularJS (2) ASP.NET (146) bicycle (2) books (214) browser (10) C# (139) cars (1) chess (30) CodePlex (11) Coma (8) database (63) deployment (3) Entity Framework (2) essay (120) flash/shockwave (2) flex (1) food (3) friend (2) game (22) idea (5) IIS (8) javascript (86) LInQ (2) Linux (6) management (4) manga (47) misc (738) mobile (1) movies (106) MsAccess (1) murder (2) music (64) mysql (1) news (101) NuGet (1) permanent (1) personal (69) PHP (1) physics (2) picture (358) places (12) politics (15) programming (536) question (2) rant (124) religion (3) science (44) Sharepoint (3) software (60) space (2) T4 (2) technology (13) Test Driven Development (4) translation (2) VB (2) video (106) Visual Studio (45) web design (47) Windows API (8) Windows Forms (3) Windows Server (6) WPF/Silverlight (64) XML (12)

Tuesday, February 09, 2010

Internal error: internal WPF code tried to reactivate a BindingExpression that was already marked as detached.

I started my WPF application and I got this weird exception: Internal error: internal WPF code tried to reactivate a BindingExpression that was already marked as detached. At the time of this entry, googling for this yields about 3 results, only one saying something about how internal WPF errors are usually multithreaded exceptions and, if you have it, try to remove IsAsync="True".

Needless to say, I didn't have that. The StackTrace of the exception was showing me, kind of obliquely, that the error was coming from a binding, but not why. Luckily, I looked in the Visual Studio Output window while getting the error. And there it was! A completely different error, this time telling me what the problem was.

Incidently, the error was caused by a style that had a BasedOn="{x:Type Something}" property setting. I know it is supposed to work, but in this case, it didn't, and it needed the more conservative yet safer BasedOn="{StaticResource {x:Type Something}}".

The cause of the error is only a detail, though, as the lesson here is to always look in the Output window while debugging WPF applications, even if you have an exception thrown. The messages there are more verbose and are actually telling you what bindings do, not what internal code is executed.


Anonymous said...

ZAM(el)! There it was, in the debug output, just like you said.

Thanks for the post.

Anonymous said...

Tks, buddy! That worked for me! That error was driving me crazy.

Another good tip to debug WPF is to use PresentationTraceSources.TraceLevel=High in the xaml binding expression.

Good work!