Anybody come across this exception before? Exception in DataPortal.Fetch() --> Ms.Wind32

Jaans posted on Monday, December 21, 2009

Hi All

I have an exception that appears to be faulting in the DataPortal stack down into Ms.Win32

Some background: This code is running under as a Windows Service project and uses background workers to divide and conquer various queud workloads. CSLA is configured with an application server (WCF) and this service connects to that WCF DataPortal.

I'm having a hard time figuring out what's the cause of the problem here.
The following is a snippet of the stack trace of the exception that's occuring in a production environment.

------------ Start Exception ----------
System.ComponentModel.Win32Exception: The system cannot find the file specified
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
at MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook[] hooks)
at MS.Win32.MessageOnlyHwndWrapper..ctor()
at System.Windows.Threading.Dispatcher..ctor()
at System.Windows.Threading.Dispatcher.get_CurrentDispatcher()
at System.Windows.DependencyObject..ctor()
at Csla.DataPortal.GetDataPortalProxy(Boolean forceLocal)
at Csla.DataPortal.Fetch(Type objectType, Object criteria)
at Csla.DataPortal.Fetch[T](Object criteria)
at XXXXX.BusinessLogic.XXXXXX.PrintXXXXXXList.Get(Int32 Id)
at XXXXXX.Service.Windows.Printing.PrintService.XXXXXPrintBackgroundWorker_DoWork(Object sender, DoWorkEventArgs e)
------------ END ----------

I have yet to be able to repro it in the dev environment and was hoping that maybe some else has run into something similar.

What's worse is that it's happening intermittendly and at some point it just returns to normal working state. In other (much worse) cases it just stops working altogether. Almost like a hang?

Any insights would greatly be appreciated?

Regards,
Jaan

RockfordLhotka replied on Monday, December 21, 2009

It looks to me like you are calling an external (unmanaged) component using p/invoke or COM? Or .NET is doing so on your behalf.

Calling unmanaged code in a multithreaded environment can be tricky, because it is often necessary to make sure the background threads have the correct context, and with COM the correct apartment model.

Paul Czywczynski replied on Monday, December 21, 2009

We started getting this exact same error on our project when we upgraded from 3.8 beta 1 to 3.8 RTM on Nov 19th. I am not sure if it was a change between those two 3.8 iterations or something further back. We jumped from 3.0.4 to 3.8 in our development a few months ago. We're currently in the process of releasing our newest application version with CSLA 3.8.

In our infrastructure we host our DataPortal WCF services in an IIS7 farm. When this error occurs, everything in that app pool stops working. All we can do is recycle the app pool and everything is fine again. This error happens at completely random times with random DataPortal_xyz methods at various server loads. Currently I am thinking it is a memory pressure thing so I moved the affected 3.8 DataPortals to their own dedicated server running Win2008 R2 x64 8GB ram with IIS7.5. It seems to help since I have not seen the error in the last week. The odd thing is we host more than two dozen DataPortals on our IIS7 farm. The other DataPortals are running CSLA 3.0.4 and when I was/am having this problem only the 3.8 DataPortals were affected. On a single server the 3.0.4 DataPortals would still be servicing 50+ connections each but the 3.8 DataPortal hung only servicing about 10 connections.

Based on my observations it seems something between 3.0.4 (or maybe 3.8 beta 1) and 3.8 RTM has caused this problem to bubble up. I can't reproduce it reliably and I can't attach a debugger to the affected 3.8 DataPortal. A Google search of "RegisterClassEx(WNDCLASSEX_D wc_d)" turns up very little besides a WPF bug a while back but that has been long fixed in the latest .NET bits we have.

At this point I am not sure where to go. It seems helpful to have more server resources available, like memory. I guess this theory will be tested during the first week of January. Our first 3.8 customer goes live and we'll be servicing about 60 user connections from them. I don't like the idea of crossing my fingers and hoping for the best. I am out of options besides going back to 3.0.4 and I really don't want to do that.

-Paul

RockfordLhotka replied on Monday, December 21, 2009

tmg4340 replied on Monday, December 21, 2009

I did some digging into the 3.7 codebase I currently have at my fingertips... I don't think 3.8 significantly changed in this area, but I think I can at least pinpoint the issue.

If you look through the stack trace, you see where it goes from the DataPortal to a DependencyObject, to a Dispatcher object, and so on and so on.  What I think is the problem is the "IsInDesignMode" property call - which uses a DependencyObject.  I haven't traced the whole thing yet, but I think the DependencyObject's potential use of a callback method to do some things is what's getting the Dispatcher involved.

(Reflector is your friend here...)

If this is the case, and WPF is trying to thread out from a spawned background thread... well, I can see the potential issues there.

In any event, I think this is a WPF/service issue.  The Google search Paul references may be the below-linked issue:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361469

Which, on the one hand, sounds like it's been resolved - but maybe not.  The article title talks about using WPF within IIS, but if you read some of the comments, it sounds like its a general WPF/service issue.

The reason I say it may not be completely resolved is that the last comment on the post (from January of this year) says the patch worked, but then goes on to present an event-log snapshot of the error.  His goes through the Media namespaces (since the ultimate basis of that post is that people are using WPF to generate images on-the-fly and serve them through IIS), but ultimately it ends up at the same place.  So I can't tell whether it's "really fixed" or not.

Given the reliance on WPF in VS 2010, one would hope that this has been resolved there (though VS isn't a good analog to using WPF in a service environment.)  But if not, the design-mode check may have to resort to some other means to avoid this...

HTH

- Scott

RockfordLhotka replied on Monday, December 21, 2009

RockfordLhotka replied on Monday, December 21, 2009

Jaans replied on Monday, December 21, 2009

Hi All

Thanks for the help!

For us, the issue has now steadily become a daily one, requiring the windows service (client) to be restarted regularly since it becomes "hung".

Here are some specific points that may help to rule some theories out or even in. Some of these are answers to questions asked in previous replies.

* We're not calling (that we directly know of) any COM object or doing interop in any of the methods indicated in the call stack.

* We are however using Log4Net for our logging.
Paul, are you also using this?

* This project is NOT using the DataAnnotations attributes on any of the classes

* Also NOT using any Async validation rules

* Generally we are using L2C, but it's NOT on the BO object referenced in the exception. In fact, the BO is a very simple Read Only Root list and Child (RoRL+RoC)

* The "client" is throwing the exception and eventually "hangs". The windows service I'm referring to is a "client" that performs automated processing. It is this service that connects to a WCF data portal host running on under different windows service on another server.

* This exception has NOT been thrown by any of our other UI clients running Windows Forms or by the ASP.NET web sites.

* We are NOT running the client (or server) under WPF nor are we making calls (directly anyway) into WPF or the WPF namespace of CSLA.

* NOT hosting the DataPortal in IIS instead we are self hosting WCF under a windows service.

* The data portal host (application tier server) is running as a Windows Service hosting the WCF Data Portal Proxy using the binary formatter (NetDataContract).

* The data portal host has not logged a single exception.

* We are running CSLA 3.8.1 RTM

* I can confirm that both the servers (hosting the dataportal and the client) are running .NET 3.5 SP1

Hope that helps!

Regards,
Jaans

RockfordLhotka replied on Monday, December 21, 2009

Jaans,

Since you have such a repeatable scenario you may be in the best position to
help test the solution.

If the theory of the design time check issue is correct, then my previous
post may contain the answer. Though since you aren't running in IIS/ASP.NET
perhaps HttpContext.Current will be null?

Is it possible to have you try making this change to the client-side
DataPortal.cs file:

public static bool IsInDesignMode
{
get
{
if (System.Web.HttpContext.Current != null ||
System.Windows.Application.Current == null)
return false;
else
return DesignerProperties.GetIsInDesignMode(new
DependencyObject());
}
}

If the issue is with GetIsInDesignMode() this may be the answer. If you are
running in ASP.NET or not in WPF then this should avoid the use of a
DependencyObject() and (probably more importantly) the DesignerProperties
type.

Jaans replied on Monday, December 21, 2009

Hi Rocky

Makes sense - I'll make the change and schedule some maintenance time to update the production servers.

Just a quick question, should the test for WPF not be System.Windows.Application.Context != null ?
(your example shows "== null" - am I missing something?)

Jaans replied on Monday, December 21, 2009

DOH!

Scratch that... I am being daft... I get it now.

It's about not being in WPF.

RockfordLhotka replied on Monday, December 21, 2009

I think I was right.

If HttpContext.Current is NOT NULL we're on a server.

OR

If Application.Context IS NULL we're on a server (or at least not in WPF)

THEN

Return false

tmg4340 replied on Monday, December 21, 2009

I don't know whether it would be worth the time to check, but I might also suggest that Jaan and Paul check to see whether the 3.5 SP1 patch referenced in the feedback link I provided is in place - or, if not, if applying it does the trick.

I'm not suggesting that re-working the design-time check isn't appropriate, and it may be an easier fix to put into place than a .NET patch.  But the patch is supposed to fix this very issue, so I thought it might be worth investigating...

- Scott

Paul Czywczynski replied on Tuesday, December 22, 2009

tmg4340:

I don't know whether it would be worth the time to check, but I might also suggest that Jaan and Paul check to see whether the 3.5 SP1 patch referenced in the feedback link I provided is in place - or, if not, if applying it does the trick.

I'm not suggesting that re-working the design-time check isn't appropriate, and it may be an easier fix to put into place than a .NET patch.  But the patch is supposed to fix this very issue, so I thought it might be worth investigating...

- Scott

Scott, shortly after this error started to appear I searched and found the MS Connect thread. I applied the patch to two of my three DataPortal servers. I reserved the third just in case the patch brought down my servers and I was without any DataPortal servers. I did take the third out of the IIS farm. I monitored for a few more days and found that the error was still happening. I then reformatted the third to make sure I had the latest bits of everything. I then moved my CSLA 3.8 DataPortals to this new third server. This is where I am today. This third server is more heavy duty so I don't have the memory pressure as I had on my previous two. Since I put this configuration into play (Dec 11th) I have not had the error but my user load is down because the customer using this build has completed their training and parallel data entry.

This is my infrastructure today:

Hosting CSLA 3.0.4 DataPortals (each server hosts about 90 to 120 connections per second daily)

DataPortal00 - Dual 2.0GHz Opteron 2212, 4GB ram, Win2008 x86 w/SP2 and WPF patch
DataPortal01 - Dual 2.0GHz Opteron 2212, 4GB ram, Win2008 x86 w/SP2 and WPF patch

Hosting CSLA 3.8.1 DataPortals (at max load it only has about 15 to 25 connections per second)

DataPortal02 - Dual 2.8 Xeon, 8GB ram, Win2008 R2 x64

RockfordLhotka replied on Tuesday, December 22, 2009

Based on the stack traces thus far, I don't think the issue is on your
server. Applying patches to the servers will probably have no impact.

It could be that applying the patches to the clients might fix the issue. It
certainly does look like the client-side data portal is failing when it
tries to get the proxy object.

JonnyBee's suggestion may be a good one, as it would eliminate the whole
design-time issue from release code, where it is useless anyway.

Paul Czywczynski replied on Tuesday, December 22, 2009

I do see your point with the stack traces. When we first came across this error I started tearing into client side code. The problem with the client side theory is once one users get the error they all start to get it. Restarting the client does not help, I have to recycle the DataPortal app pool and then everyone can connect again. Another odd thing is I would think this bug would consistently come up and not be as random as it is. In our experience it seems to work for a few hour to a few days and then boom, it all goes down until I recycle the app pool. We're going thru our DataPortal code looking for any obvious memory leaks that would add pressure to the system but we haven't found anything significant yet.

Jaans replied on Tuesday, December 22, 2009

We managed to get a new customised version of our system into Production yesterday in order to test a potential solution to the problem (that would be Rocky’s suggestion to test a different IsInDesignMode implementation).

Again, for clarity's sake I'll detail what’s changed and where.

Application Tier: We have a dedicated data portal host running in it's own Windows Service that services CSLA Data Portal requests over WCF. It services connections from 3 sources/clients:
A. another Windows Service that performs automation and printing
B. 50+ Windows Forms Applications
C. 4-Server web farm running ASP.NET

The errors we were experiencing were only showing up on the Windows Service A. (which is a Client in terms of architecture).

The other clients B. C. have no such exception showing in the logs or otherwise reported. The application server (aka. data portal host) also did not have any exceptions.

I've only updated A. and the modified CSLA 3.8.1 is only deployed to A. The Application Server (Data Portal Host) and the other clients B. C. are still running the original CSLA without the change.

Is it working?
Well, so far it's looking good - for the past 20 hours the exception hasn't occurred again. I'll keep monitoring and will only draw a conclusion that it has been resolved if after a week we don't see it again (because it's such an intermittent issue).

Questions / possible conclusions:
* Considering that only one client was changed (A), that the issue is indeed a client side issue and has nothing to do with the server side of the data portal?

That said, what Paul is experiencing in the IIS environment may actually be due to an (side) effect the issue may have on the WCF stack, perhaps causing it to leak connections? Interestingly I've run into issue in the past we're if code doesn't "guarantee" WCF connections to be closed and disposed that you suddenly start running out of available connections and your scaling declines. Perhaps it's related to what we interpret as the "hang" which in itself doesn't raise / throw exceptions - just stops working from the client's point of view. Paul's mileage may vary.

* I'm not so sure about a compiler directive since we treat CSLA as a 3rd party black box and so our development only uses Release builds of CSLA, even when still doing development. That could mean we would always be excluded from the "Design Time Experience" offered by CSLA if using compiler directives.

* It all may be a moot point with the advent of VS2010, so perhaps the suggested change is sufficient to carry us over until then. As a point of curiosity, what is the "new way" with VS 2010?

* What are the practical ramifications for development if the IsInDesignTime property just returns false? E.g. Would Grids (windows or web) still discover the properties of the BO, etc.?

RockfordLhotka replied on Wednesday, December 23, 2009

And the change you made was to ensure that IsInDesignMode returns false?

If that property was, for example, hard-coded to return false the only impact is that no design time sample data would be rendered in Expression Blend or VS08 when someone is designing a XAML UI that binds to a business object.

The designer still works, there's just no generated sample data.

As I mentioned, VS10 has a different model for generating sample data in the designer, so as far as I know this whole feature of the data portal becomes meaningless in 4.0.

Jaans replied on Wednesday, December 23, 2009

Here is the changed code (DataPortal.cs):

#region Design Time Support

///
/// Gets a value indicating whether the code is running
/// in WPF design mode.
///
public static bool IsInDesignMode
{
get
{
if ( System.Web.HttpContext.Current != null || System.Windows.Application.Current == null )
return false;
else
return DesignerProperties.GetIsInDesignMode( new DependencyObject() );
}
}

#endregion

So if I understand correctly, having that property always return false will just impact having dummy/sample data when binding UI in XAML?

Furthermore, it does not affect Web Applications or Windows Forms Application's ability to discover the "Schema" of the business object? (Not talking about data for that schema, merely that the designer knows that there is (for example) an OrderId property that is read only on the BO?

If that's the case I personally am not bothered to have sample data for XAML UI Binding. Not sure about other users, but for us it would not impact productivity or ease of use of CSLA business objects in the respective designers.

Ps: I just checked the logs again, and the exception hasn't happened yet, so good news.

RockfordLhotka replied on Wednesday, December 23, 2009

Thanks. That change will work for you, because your "client" is not a WPF app.

It probably won't help others who are seeing the issue when using a WPF client app, because the DesignerProperties call would still be made, and that sure seems to be the core problem.

I am beginning to think that 3.8.2 should either always return false (kind of in preparation for 4.0).

Or I could add a config switch that you'd set in production - like CslaDataPortalDisableDesignMode - to turn off the feature. I'm not real happy about adding yet another config switch, but I also don't see a clean answer to this problem.

It seems pretty obvious that we're dealing with some sort of bug in WPF...

RockfordLhotka replied on Wednesday, December 23, 2009

Paul Czywczynski replied on Wednesday, December 23, 2009

I grabbed 3.8.2 and hardwired the getter to return false. I'll deploy it out to our live customer over lunch and switch them back to our normal IIS farm from their dedicated DataPortal server. Being the holidays I don't think it'll get hammered too much so it might take a while to pop up again if this didn't fix it. I'll report back if I find anything out in the meantime.

ajj3085 replied on Wednesday, December 23, 2009

Can't put it in devenv.exe.config or blend.exe.config?

Paul Czywczynski replied on Thursday, December 31, 2009

Quick follow up. Everything has been good this week. If we make it thru next week then I think we found the problem.

-Paul

Jaans replied on Thursday, December 31, 2009

Same here.

Been running since 22 Dec without issue.

Jaans

Paul Czywczynski replied on Monday, December 21, 2009

Follow up on previous questions.

- No DataAnnotations

- No async validation rules

- No Linq to CSLA

- Our DataPortal_XYZ methods do not make any calls to WPF. The client is WPF but we have not yet experienced the error in 2-tier mode.

- We're using NLog on both the client and server.

- We upgraded all our clients and servers to 3.51 at the beginning of this year.

- We do host the WCF service in IIS. Inside of the WCF service on IIS we do impersonate an ActiveDirectory user to gain access to the SQL Server.

Like Jaans, the client throws the error, nothing is reported on the DataPortal server.

-Paul

RockfordLhotka replied on Monday, December 21, 2009

Paul,

If the exception occurs on the client, then it is in WPF right? If that is
true then my suggestion won't help, because the existing code will still run
since it is in WPF.

I suppose we could consider removing the design-time support concept from
the data portal. VS10 uses a different model for generating design time data
anyway, so this idea of detecting design time in the business layer is
probably not useful long-term regardless.

I suppose one thing to try, as a test, would be to hard-code the design time
method in DataPortal.cs to just always return false - entirely eliminating
the actual check.

JonnyBee replied on Tuesday, December 22, 2009

Hi all,

How about adding a compiler directive:

    public static bool IsInDesignMode
    {
      get
      {
#if DEBUG
          return DesignerProperties.GetIsInDesignMode(new DependencyObject());
#else
          return false;
#endif
      }
    }

System.Windows.Application (and DependencyObject) both inherits from System.Windows.Threading which seems to be where the exception occurs. The constructor for System.Windows.Application (following the Singelton pattern) also creates threads and calls BeginInvoke.

After all -this is a support feature for development and I would propose to exclude that feature from a  "Release" build.

Another solution would be to add a new configuration flag like ForceNoDesignMode and test for this flag before DesignerProperties is called if you need to have a release build with designer support.

Would it be possible for you guys to try this out in your environment?

Paul Czywczynski replied on Tuesday, December 22, 2009

Rocky, this is the exception from one of our customer's client application log file. This is the only time I see the error, when it is returned in a DataPortalException. Nothing is ever logged on the server. It's a cascade affect. Once one client instance fails with this error they all start to fail until that DataPortal's app pool is restarted.


=== Unhandled Exception occured ===
DateTime: 12/2/2009 12:24:29 PM
FX Version: 14.2.9336.1007
OS Version: Microsoft Windows NT 5.2.3790 Service Pack 2
TWFX.exe Error: 0 : Csla.DataPortalException: DataPortal.Fetch failed (The system cannot find the file specified) ---> Csla.Reflection.CallMethodException: DataPortal_Fetch method call failed ---> System.ComponentModel.Win32Exception: The system cannot find the file specified
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
at MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook[] hooks)
at MS.Win32.MessageOnlyHwndWrapper..ctor()
at System.Windows.Threading.Dispatcher..ctor()
at System.Windows.Threading.Dispatcher.get_CurrentDispatcher()
at System.Windows.DependencyObject..ctor()
at Csla.DataPortal.GetDataPortalProxy(Boolean forceLocal)
at Csla.DataPortal.Fetch(Type objectType, Object criteria)
at Csla.DataPortal.Fetch[T](Object criteria)
at TWFX.BusinessObjects.Entities.Tasking.WorkflowOriginCollection.GetWorkflowOriginCollection(Byte[] TS, LinkingType Type)
at TWFX.BusinessObjects.Entities.Tasking.ScheduledNotificationCollection.ExecuteFetch(FilterCriteria criteria)
at TWFX.BusinessObjects.Entities.Tasking.ScheduledNotificationCollection.DataPortal_Fetch(FilterCriteria criteria)
at dm(Object , Object[] )
at Csla.Reflection.MethodCaller.CallMethod(Object obj, DynamicMethodHandle methodHandle, Object[] parameters)
--- End of inner exception stack trace ---
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
at MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook[] hooks)
at MS.Win32.MessageOnlyHwndWrapper..ctor()
at System.Windows.Threading.Dispatcher..ctor()
at System.Windows.Threading.Dispatcher.get_CurrentDispatcher()
at System.Windows.DependencyObject..ctor()
at Csla.DataPortal.GetDataPortalProxy(Boolean forceLocal)
at Csla.DataPortal.Fetch(Type objectType, Object criteria)
at Csla.DataPortal.Fetch[T](Object criteria)
at TWFX.BusinessObjects.Entities.Tasking.WorkflowOriginCollection.GetWorkflowOriginCollection(Byte[] TS, LinkingType Type)
at TWFX.BusinessObjects.Entities.Tasking.ScheduledNotificationCollection.ExecuteFetch(FilterCriteria criteria)
at TWFX.BusinessObjects.Entities.Tasking.ScheduledNotificationCollection.DataPortal_Fetch(FilterCriteria criteria)
at dm(Object , Object[] )
at Csla.Reflection.MethodCaller.CallMethod(Object obj, DynamicMethodHandle methodHandle, Object[] parameters)
at Csla.Reflection.MethodCaller.CallMethod(Object obj, DynamicMethodHandle methodHandle, Object[] parameters)
at Csla.Reflection.MethodCaller.CallMethod(Object obj, String method, Object[] parameters)
at Csla.Server.SimpleDataPortal.Fetch(Type objectType, Object criteria, DataPortalContext context)
--- End of inner exception stack trace ---
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
at MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook[] hooks)
at MS.Win32.MessageOnlyHwndWrapper..ctor()
at System.Windows.Threading.Dispatcher..ctor()
at System.Windows.Threading.Dispatcher.get_CurrentDispatcher()
at System.Windows.DependencyObject..ctor()
at Csla.DataPortal.GetDataPortalProxy(Boolean forceLocal)
at Csla.DataPortal.Fetch(Type objectType, Object criteria)
at Csla.DataPortal.Fetch[T](Object criteria)
at TWFX.BusinessObjects.Entities.Tasking.WorkflowOriginCollection.GetWorkflowOriginCollection(Byte[] TS, LinkingType Type)
at TWFX.BusinessObjects.Entities.Tasking.ScheduledNotificationCollection.ExecuteFetch(FilterCriteria criteria)
at TWFX.BusinessObjects.Entities.Tasking.ScheduledNotificationCollection.DataPortal_Fetch(FilterCriteria criteria)
at dm(Object , Object[] )
at Csla.Reflection.MethodCaller.CallMethod(Object obj, DynamicMethodHandle methodHandle, Object[] parameters)
at Csla.Reflection.MethodCaller.CallMethod(Object obj, DynamicMethodHandle methodHandle, Object[] parameters)
at Csla.Reflection.MethodCaller.CallMethod(Object obj, String method, Object[] parameters)
at Csla.Server.SimpleDataPortal.Fetch(Type objectType, Object criteria, DataPortalContext context)
at TWFX.Win.Helpers.ExceptionHandler(Exception exception, Boolean AllowNavigateBack)
at TWFX.Win.App.ExceptionHandler(Object sender, Exception e)
at TWFX.Win.App.Current_DispatcherUnhandledException(Object sender, DispatcherUnhandledExceptionEventArgs e)
at System.Windows.Threading.Dispatcher.CatchException(Exception e)
at System.Windows.Threading.Dispatcher.CatchExceptionStatic(Object source, Exception e)
at System.Windows.Threading.ExceptionWrapper.CatchException(Object source, Exception e, Delegate catchHandler)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Boolean isSingleParameter)
at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority priority, Delegate method, Object arg)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
at System.Windows.Window.ShowHelper(Object booleanBox)
at System.Windows.Window.Show()
at System.Windows.Window.ShowDialog()
at TWFX.Win.MainWindow.OpenDialog(Window dlg, Boolean isModal)
at TWFX.Win.MainWindow.AddAssociateCommandExecuted(Object sender, ExecutedRoutedEventArgs e)
at System.Windows.Input.CommandBinding.OnExecuted(Object sender, ExecutedRoutedEventArgs e)
at System.Windows.Input.CommandManager.ExecuteCommandBinding(Object sender, ExecutedRoutedEventArgs e, CommandBinding commandBinding)
at System.Windows.Input.CommandManager.FindCommandBinding(CommandBindingCollection commandBindings, Object sender, RoutedEventArgs e, ICommand command, Boolean execute)
at System.Windows.Input.CommandManager.FindCommandBinding(Object sender, RoutedEventArgs e, ICommand command, Boolean execute)
at System.Windows.Input.CommandManager.OnExecuted(Object sender, ExecutedRoutedEventArgs e)
at System.Windows.UIElement.OnExecutedThunk(Object sender, ExecutedRoutedEventArgs e)
at System.Windows.Input.ExecutedRoutedEventArgs.InvokeEventHandler(Delegate genericHandler, Object target)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
at System.Windows.UIElement.RaiseEvent(RoutedEventArgs args, Boolean trusted)
at System.Windows.Input.RoutedCommand.ExecuteImpl(Object parameter, IInputElement target, Boolean userInitiated)
at System.Windows.Input.RoutedCommand.ExecuteCore(Object parameter, IInputElement target, Boolean userInitiated)
at MS.Internal.Commands.CommandHelpers.CriticalExecuteCommandSource(ICommandSource commandSource, Boolean userInitiated)
at System.Windows.Controls.Primitives.ButtonBase.OnClick()
at System.Windows.Controls.Button.OnClick()
at System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs e)
at System.Windows.UIElement.OnMouseLeftButtonUpThunk(Object sender, MouseButtonEventArgs e)
at System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent)
at System.Windows.UIElement.CrackMouseButtonEventAndReRaiseEvent(DependencyObject sender, MouseButtonEventArgs e)
at System.Windows.UIElement.OnMouseUpThunk(Object sender, MouseButtonEventArgs e)
at System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
at System.Windows.UIElement.RaiseEvent(RoutedEventArgs args, Boolean trusted)
at System.Windows.Input.InputManager.ProcessStagingArea()
at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Boolean isSingleParameter)
at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority priority, Delegate method, Object arg)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.Run()
at System.Windows.Application.RunDispatcher(Object ignore)
at System.Windows.Application.RunInternal(Window window)
at System.Windows.Application.Run(Window window)
at System.Windows.Application.Run()
at TWFX.Win.App.Main()
ProcessId=25616
ThreadId=1

RockfordLhotka replied on Tuesday, January 12, 2010

Is this the final solution:

    public static bool IsInDesignMode
    {
      get
      {
        if (System.Web.HttpContext.Current != null || System.Windows.Application.Current == null)
          return false;
        else
          return DesignerProperties.GetIsInDesignMode(new DependencyObject());
      }
    }

Now that a couple of you have run this (or some) code for a while, is this a good solution?

Or did you entirely disable design mode by hard-coding this to return false?

Paul Czywczynski replied on Tuesday, January 12, 2010

I hard-coded a return false because us old school xaml guys never use a designer :)

chachek replied on Wednesday, May 05, 2010

We just started getting this exception.

Rocky, is this fixed in most current release of CSLA 3.8.x ?

tmg4340 replied on Tuesday, December 22, 2009

I may be wrong, but I don't think Paul is saying the exception is happening on his WPF client - I think he's saying he doesn't see it until it gets back to his client.  If you look at Paul's stack trace, the exception is coming back in a DataPortalException, so I think it's still happening in his IIS-hosted WCF DataPortal - which should still fit the criteria for the potential issue.

Like I said earlier, I still think it would be useful to re-work the design-time indicator, especially in light of your comments about how VS changed design-time behavior in VS 2010 anyway.  While I'm not a fan of compiler directives, Jonny's suggestion isn't a bad one - presumably, people aren't using debug builds in production, and they probably aren't using debug builds for load-testing either.  Other than that, I think the "Are we on the server?" checks we have would be another good place to start.  While the System.Windows.Application object does use some of the same threading code as a DependencyObject, the "Current" property is guaranteed to be thread-safe, which may combat this issue.

HTH

- Scott

RockfordLhotka replied on Tuesday, December 22, 2009

RockfordLhotka replied on Tuesday, January 12, 2010

That's why I'm asking :)

It might be simplest to just make 3.8.2 return false and be done with it, as in 4.0 I plan to drop the concept entirely anyway.