locked
How do I debug LIghtSwitch hang RRS feed

  • Question

  • I have a screen which has a custom SL control that I have created on it.  The custom control displays an Org chart and works just fine until....  The problem is switching to another screen or trying to close the screen with the custom control on it.  If I click on the tab for another screen nothing happens, the current screen does not disappear.  After about one minute the window is blanked with just the title bar and frame displayed.  I have an eight core machine and one core is consumed by sllauncher when the application is stuck.  The memory usage of sllauncher ramps up from ~150MB to ~950MB and stops there.  I use 'Stop Debugging' in VS to escape.

    If I remove my custom control from the screen then everything behaves as normal so I am pretty sure it is my fault (duh)

    My control is a list box with a custom layout panel.  I have tried putting breakpoints in the MeasureOverride and ArrangeOverride methods but the breakpoints are only hit at sensible times (when the DataContext changes) and are not hit after I try to switch to another screen.

    I have set the screen to 'Use Read-only Controls'.

    I have tried adding  ScreenName_Saving and ScreenName_Closing handlers with breakpoints but things seem to behave sensibly.

    I have tried with both Standard Shell and Cosmopolitan shell.

    My question is, How do I debug this problem?  I don't know how to dig into whatever is happening.

    Does anyone have an suggestions on how to proceed with debugging this problem? Is there some way to produce trace output to workout what is getting stuck?  If I do a Break All while the program is hung the stack looks like

    > System.dll!System.Net.SafeCloseSocket.InnerSafeCloseSocket.Accept(System.Net.SafeCloseSocket socketHandle, byte[] socketAddress, ref int socketAddressSize) + 0xf bytes 
      System.dll!System.Net.Sockets.Socket.Accept() + 0x77 bytes 
      Microsoft.LightSwitch.Server.Host.dll!Microsoft.VisualStudio.WebHost.Server.OnStart6(object unused) + 0x2d bytes 
      mscorlib.dll!System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(object state) + 0x3e bytes 
      mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0xa7 bytes 
      mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x16 bytes 
      mscorlib.dll!System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x60 bytes 
      mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x149 bytes 
      mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback() + 0x5 bytes 
      [Native to Managed Transition] 


    Paul Linton

    Tuesday, January 29, 2013 9:14 AM

Answers

  • Try reproducing the problem again and do a Break All again. You'll probably see a call stack on the server (like you have above). What you need to do is open the Processes or Threads window (Debug -> Windows -> [Processes|Threads]). You can double-click the sllauncher process (Silverlight Out-Of-Browser) in the Processes window, iexplore (Silverlight In-Browser) in the Processes window, or a thread in the Threads window under sllauncher or iexplore.

    Basically, you just need to switch to the running client. From here, you can then see what is causing the memory build-up (maybe your control is causing a stack overflow or out of memory exception) and eventual hang.


    Justin Anderson, LightSwitch Development Team

    Tuesday, January 29, 2013 11:30 AM
    Moderator

All replies

  • Try reproducing the problem again and do a Break All again. You'll probably see a call stack on the server (like you have above). What you need to do is open the Processes or Threads window (Debug -> Windows -> [Processes|Threads]). You can double-click the sllauncher process (Silverlight Out-Of-Browser) in the Processes window, iexplore (Silverlight In-Browser) in the Processes window, or a thread in the Threads window under sllauncher or iexplore.

    Basically, you just need to switch to the running client. From here, you can then see what is causing the memory build-up (maybe your control is causing a stack overflow or out of memory exception) and eventual hang.


    Justin Anderson, LightSwitch Development Team

    Tuesday, January 29, 2013 11:30 AM
    Moderator
  • Spot on.

    I was just about to post that I had tracked down the problem using exactly the method you suggested.

    FWIW - I have a LayoutUpdated handler in the SL custom control and in that it does a TransformToVisual operation.  The TransformToVisual was throwing an ArgumentException which seemed to cause a new pass of LayoutUpdated, no escape.  When trying to remove the control I assume that something has been removed from the Visual Tree and calling TransformToVisual is then a bad thing to do.  Some protection prior to calling TransformToVisual seems to have fixed the problem.


    Paul Linton

    Tuesday, January 29, 2013 11:37 AM