0

I am developing a C# Winforms CMS application which maintains data in an Access database via OleDb and posts elements of it to a web backend. My issue seems to be the same as the one found here: SO question on tracing a 'module not found' error in that I too run my application then it bombs out after about 20 seconds with the 'module not found' error.

I can't identify anything that I have changed in the code that could have triggered this; I've basically been working on refining the population of a list in a form with data retrieved from the db - something I've been doing extensively throughout development - and besides the occasional application crash which I've "solved" by restarting VS2022, things have been going OK. No new classes have been created prior to the onset of the issue.

The crash seems to be entirely time driven - i.e. it makes no difference what I do in the UI. A "catch all" try...catch in Program.cs does not catch any exception.

The searches that I have done with the error number seem to reference an issue with Kernelbase.dll but alas I am sufficiently unskilled to establish how/where my code references this library. A contributor to the referenced question suggests "capture a crash dump and analyze it with WinDbg", but (having read the MS page on getting started with WinDbg) I literally have no idea how I would do this, or what I would be looking for.

On the advice found on an MS forum, I ran "sfc /SCANNOW" which "found corrupt files and successfully repaired them". This had no apparent impact on the issue.

Please could you point me in the direction where I might find out what is going on and how to fix it?

Z

PS/ This may be the same error as described here too - but I'm not explicitly/knowingly calling any new dll, nor working in c++.

ZG862
  • 1
  • 5
  • You can use [FusLogvw](https://learn.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer) or [WinDbg](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/windbg-overview) – Max Apr 19 '23 at 09:52
  • A 20 second timeout sound more like a timeout occurring while app is trying to get authorization to a remote machine from a Password Server. You are using Windows Credentials and all your machines are in the same Windows Group. There are one or more Password servers that give access to remote machines. Occasionally Timeouts will occur when attempting a remote connection. – jdweng Apr 19 '23 at 09:53
  • Thanks @jdweng - I'll take a look at that. I do have a call to WindowsIdentity.GetCurrent() that I can remark out. – ZG862 Apr 19 '23 at 10:15
  • You need a stacktrace at a minimum. Doesn't the application event log have a crash record? Setup user mode dumping if you haven't already: https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps and you might need to bite the bullet and get up to speed with windbg. Do note that MS Access is a COM based application and with its OLE driver that loads into the process memory of your app. That brings in a **LOT** of dependencies that all might have several fail cases, ending in the conclusion that its not your app fault a crash happens. – rene Apr 19 '23 at 10:18
  • Microsoft has some deep dive videos in windbg in their Defrag Tools show: https://learn.microsoft.com/en-us/Shows/Defrag-Tools/?terms=windbg those, take you from beginner level into more advanced features as you go. – rene Apr 19 '23 at 10:26
  • Thank you @rene. That has given me some avenues to follow. Whilst the application relies on it's database interaction, I could start by temporarily disabling the call I make in Program.cs to make the connection to it and see if it changes anything. Remarking out calls to WindowsIdentity didn't make a difference, so it looks likely that I'm going to be acquiring some basic WinDbg skills! :) – ZG862 Apr 19 '23 at 10:48
  • _posts elements of it to a web backend._: What does this mean? The following may (or may not) be helpful: [Considerations for server-side Automation of Office](https://support.microsoft.com/en-us/topic/considerations-for-server-side-automation-of-office-48bcfe93-8a89-47f1-0bce-017433ad79e2) – Tu deschizi eu inchid Apr 19 '23 at 14:46
  • _besides the occasional application crash which I've "solved" by restarting VS2022, things have been going OK_: You may consider creating a [minimal, reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) and posting it on SO. Without any code, it's impossible to know why you're experiencing issues. – Tu deschizi eu inchid Apr 19 '23 at 14:56
  • 1
    0xc06d007e is generated for a delay-loaded DLL that, when needed, could not be found by the OS. Diagnosing needs to start by first identifying the name of that DLL, next where exactly it looked for the file. Both tasks are most easily done by SysInternals' Process Monitor. You'll get a big trace, given the delay, work backwards. – Hans Passant Apr 19 '23 at 16:21
  • OK guys. I now have WinDbg installed and have made the requisite registry changes to capture a dump file which I have loaded into WinDbg. This gives me a call stack (which is not as familiar to me as the call stack within VS but I get that it is showing the hierarchy of calls leading to the error.) Not sure what the etiquette is regarding posting large chunks of debug analysis, but my (noob) reading of what I see on the screen is that the issue occurs with mso.dll - which a little detective work shows to be a microsoft office library. I get: APPLICATION_FAULT_c06d007e_mso.dll!Unknown. – ZG862 Apr 20 '23 at 10:13
  • mso.dll appears to have updated on the 15th of this month - presumably as part of Office Update. Does this suggest a compatibility issue with the latest file or am I being over-simplistic? – ZG862 Apr 20 '23 at 10:21
  • Yep. Sure enough, no database initialisation, no crash. But no useful application either, so I don't know how to proceed (other than to port the db to mySQL and re-write my data access layer). – ZG862 Apr 20 '23 at 16:38

1 Answers1

-1

Bingo! It turns out that the issue lies somewhere in MS Office - probably within mso.dll. I'm sure there's a responsible way to go, reporting the issue to Microsoft along with a reproducible code example - but I'm on a mission with my project, so I sidestepped it by following the instructions here to revert Office to Version 16.2302 Build 16130.20332. This has entirely eliminated the crash.

Many thanks to all who helped along the way - particularly @rene who got down to my level. :)

Z

PS/ If anyone can give me a pointer as to how to report the issue, maybe I'll get back to it when I'm done.

ZG862
  • 1
  • 5