What Debugging Steps Should I Take

Question

In a wpf application, there is one window (Transactions) that, when a use makes a ComBox selection, opens another window (Details) using this code:

Dim win As New TransactionDetails With {.Owner = Me}
If win.ShowDialog() Then SaveTransaction()

The TransactionDetails window includes a UserControl (Categories) so the Loaded event of Categoies window runs:

Private Sub LoadMe(sender As Object, e As RoutedEventArgs) Handles Me.Loaded
	If ocCategories.Count = 0 Then PopulateCategories()
	win = Window.GetWindow(Parent)
	....
	cvsCategories = CType(Resources("cvsCategories"), CollectionViewSource)
	cvsCategories.Source = ocCategories
End Sub

When the End Sub line runs, the application pauses for about a second then just quits. No error messages. Nothing in the Output window. The CallStack window shows the expected calls but gets wiped clean when the application goes south. The XAML Binding Failures has no entries. Using Watch windows shows all variables have expected values.

I don't know what further debugging steps will tell me what the problem is. Any suggestions?

Answer 1

The fact that the application exits without an exception message, and that the Call Stack disappears, suggests that you should investigate whether the process is terminating unexpectedly rather than assume that the Loaded event is throwing an ordinary exception. In WPF, this can happen because of an unhandled exception on another dispatcher or thread, an explicit application shutdown, a native or runtime failure, or an exception that Visual Studio is not configured to break on. The one-second delay after End Sub is also significant: the failure may occur during subsequent WPF layout, data binding, rendering, or another event rather than inside LoadMe itself.

I would approach this systematically, starting with the following steps.

First, configure Visual Studio to break when an exception is thrown. Open Debug → Windows → Exception Settings and enable breaking on thrown exceptions for Common Language Runtime Exceptions. Run the application again. This is important because an exception may be caught internally by WPF or your application, or may occur after your event handler returns. If Visual Studio breaks on an exception, inspect the exception type, message, and call stack before continuing. If the application still exits without breaking, that points toward a different kind of termination or a failure outside the normal managed exception path.

Second, determine whether the application is actually crashing or shutting down normally. Add temporary diagnostic code to the application-level App.xaml.vb file. In the Application_Startup event, register handlers for AppDomain.CurrentDomain.UnhandledException and TaskScheduler.UnobservedTaskException, and add a handler for Application.Current.DispatcherUnhandledException. Log the exception details to a text file rather than relying solely on the Output window. For example, the dispatcher handler can log e.Exception.ToString(). Do not automatically mark the exception as handled while investigating, because that can conceal the underlying problem. Note that these handlers cannot capture every type of process termination, and UnobservedTaskException is not a general-purpose handler for all asynchronous failures.

Third, add logging immediately after the Loaded handler returns and around the dialog call. In the Transactions window, temporarily change the code to log before and after ShowDialog() and before and after SaveTransaction(). In Categories, log the entry to LoadMe, the completion of PopulateCategories(), the assignment to win, the retrieval of cvsCategories, the assignment of its Source, and the final exit from the handler. Include timestamps in each entry. This will tell you whether the process terminates while the dialog is still open, while WPF is processing the next layout or rendering cycle, or after the dialog closes and execution returns to Transactions.

Fourth, investigate the CollectionViewSource and its associated XAML. The code shown does not, by itself, identify an obvious cause of process termination. Nevertheless, temporarily comment out cvsCategories.Source = ocCategories and test again. If the application stops exiting, investigate what the view source triggers: collection-change notifications, sorting or grouping logic, converters, data templates, and event handlers that execute when the view refreshes. If commenting out the assignment makes no difference, restore it and test with PopulateCategories() temporarily disabled. These controlled tests can isolate the component that triggers the problem.

Fifth, check the application's shutdown configuration. Look at ShutdownMode in App.xaml and any code that calls Application.Current.Shutdown(), closes the main window, or handles the Closing and Closed events. Your use of ShowDialog() makes TransactionDetails a modal window, but the fact that Transactions is its owner does not prevent the application from shutting down for other reasons. If the application is configured with ShutdownMode="OnLastWindowClose", closing the last open window will end the application. Check whether any code closes either window unexpectedly or whether a binding, event handler, or validation routine triggers a close operation.

Sixth, check the Windows application and crash logs. Open Windows Event Viewer and inspect Windows Logs → Application around the time of the failure. Look for entries from .NET Runtime or Application Error, including the exception code, faulting module, and application name. A native access violation or another runtime-level failure may terminate the process without producing a normal managed exception or a useful WPF binding error. If you find an event, the faulting module and exception code will help narrow down the investigation.

Seventh, inspect the window and control lifecycle. Since the failure appears shortly after the Categories.Loaded handler finishes, temporarily add handlers for Unloaded, Closing, and Closed on the relevant windows, and log when they fire. Also inspect any Dispatcher.BeginInvoke, asynchronous tasks, timers, event subscriptions, or callbacks initiated by PopulateCategories() or by code that runs when the category collection changes. The code executing immediately after End Sub may be the trigger, even if the debugger appears to implicate that line.

One detail worth checking in your existing code is win = Window.GetWindow(Parent). The method returns the window containing the specified element, or Nothing if the element is not attached to a window. Since you report that the value is correct in the Watch window, this is probably not the immediate issue. However, if win is later used by event handlers or asynchronous callbacks, verify that those callbacks are not acting on a window that has already closed.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin