What steps can I take to debug an issue with a deployed program having an AccessViolationException?

Question

I've spent some time looking into this problem for the last week or so. I've seen several threads on StackOverflow about AccessViolationException, but I haven't been able to find anything super applicable, especially considering the exception is so wide ranging.

The program I'm working on is a relatively straightforward C# WPF application that has an integration with another application's (not developed internally) COM objects, and uses worker threads via Task methods to process information and await responses from the COM object, to keep everything separated between the UI and the integration. I have a static class that holds a reference to the COM object, and through which I route all of the Task calls to interface with the other application. .NET 8.0 runtime, deployed onto our server using ClickOnce, with the runtime and libraries all bundled in the installation for ease of use and to remove administration requirements for installation and updating.

Big issue - on an end user's computer, though not my own, the application crashes after linking to the COM application with an AccessViolationException, detailing that a thread has tried to access some memory that it doesn't have access to. The COM application visibly opens in the background before the entire process crashes.

Program starts with a main window pane, and a button to trigger the actual connection process with the other application's COM object. Once everything is valid, the interactions with the other application are opened up.

I've sent a demo version to an end user to start testing. They downloaded it through the ClickOnce deployment. It opens up fine, but it crashes after using the button to open up the COM object interface - specifically, some time after using App = new ComApplication();, where ComApplication is the interface in question. We can see the ComApplication open up in the background, but a few seconds later it crashes.

Built the reference to the COM interface off of some (old and not-perfectly documented) examples from the ComApplication developers. I added a COM reference in my project to their Interop.Application library. I'm using "Embed Interop Types = Yes" and "Copy Local = Yes". From what I can tell, the "Interop.Application" library is not embedded into the published assembly that I send, but the COM interface is registered on the user's laptop as well.

Using logging, it crashes between creation of the ComApplication instance and calling any field or method on it (this is all on a Task thread!):

App = new ComApplication();

if (App = null) {
    Logger.Error("Failed to open the Com Object!");
    return false;
}

Logger.Info("COM object open!");

// Crashes before the next log call.
App.Visible = true;

Logger.Info("COM app visible!");

Sent an updated build through ClickOnce using the Debug configuration to try and get more information. Grabbed the .dmp file and worked through some of what's going on. It's giving the specific error: "0xC0000005: The thread tried to read from or write to a virtual address for which it does not have the appropriate access."

Despite using the DebugType "portable" or "embedded" in the csproj file, the .dmp file has not changed in size, and I've not been able to navigate the call stack with references my own assembly's source code or find the PDB. The result "not all symbols could be found" was triggering for my own assembly - it was fixed after setting DebugType - but that is triggering for some NuGet packages I'm utilizing, and my own assembly is triggering the result "not all symbols have Source Link information". I'm not sure what the purpose of Source Link would be if I'm also sending out symbols with the application, and I don't know if having the source link is relevant for internal applications (though happy to be informed otherwise!)

Importantly - this program works completely fine on my own laptop. Regardless of mode - running through the ClickOnce deployment, or through the Visual Studio 2022 debugger, etc. - there are no issues with it. At least, at this level. We're running the same OS, with the same architecture, and the runtime should be functionally identical due to the embedding of .NET assemblies.

Cut out specific calls to the COM interface that seemed to be breaking and worked out that any calls to it break.

Added line-by-line logging to interrogate the program at various steps of runtime.

Published the application using Debug configuration and embedded the symbols into the assembly.

Published under a specified platform architecture (x86) instead of "anycpu" to resolve if it's something to do with the end result assembly.

Planning on testing this issue on another one of my workstations, but the COM application needs to be installed first.

I'm relatively new to this level of programming, and I'm having a hard time wrapping my head around the steps to take to utilize the crash dump file and get more information from what was happening at the time of the crash.

Thank you!