4

App is crashing at startup and Application Error in Event Log gives the following info:
Faulting module name: KERNELBASE.dll, version: 6.2.15063.483, time stamp: 0xc3955624
Exception code: 0xe0434f4d
Fault offset: 0x000eb802

Here's the back story
On one of our customer's networks, our app is crashing before it can even open. I've now spent days searching for answers and haven't been able to solve this yet. I started with some basic troubleshooting, and after not finding any smoking gun, but finding that a new user profile solved the issue, I suggested that was a good fix to get back up and running again. Their outsourced IT agreed at first but is having difficulties migrating user data to a new profile and has never been able to finish moving the affected user to a new profile. Now the issue is occurring on another machine on their network and they are pushing back stating that the issue is with our application and we should spend the time to fix it. I agree that if it's in our code we should fix it, but so far it seems it doesn't even get far enough to reach our code. Also, we have not seen this anywhere else except on this one network with the two accounts that are logging into a domain PC with a local account.

Application Info

  • VB.NET Windows Forms app, targeting .NET 4.5
  • Yes, there is an Application Event handler present UnhandledException in the ApplicationEvents.vb file.

User Environment Info

  • Domain Network, on a Domain PC, but logged in with a non-domain Local Account with Local Administrator account type. The two users that this affects are both logging in with local accounts. So far, this does not affect anybody logging in with a domain account.
    EDIT: Correction, the second PC this is occurring on is actually not joined to the domain.
  • Workstation is running Windows 10 Pro v1703 with updates current
  • Application starts up fine if ran Elevated, but this causes other issues later so having them always run as administrator is not an acceptable solution.
  • The Application ran fine on this PC until a recent update.
  • The issue does not occur if we log in with a new domain or non-domain account with or without local admin rights. It seems to be only related to the specific user profile seeing the issues

Troubleshooting thus far

  • Read dozens of posts online dealing with kernelbase.dll crashes and couldn't find one that had a fix that worked
  • Uninstalled and reinstalled the application
  • Uninstalled and reinstalled .NET using Add/Remove Windows Components
  • Added some event log entries in the Application.Startup event and the Load event on the Splash screen and Startup form to see if we were getting that far. Tested this on working stations and logging is successful. On affected machines, no logging occurs, so it seems that the crash is happening even before the Application.Startup event.

  • Used ProcMon to monitor the app while it crashed and the last line before the Process Exits is an Operation QueryNameInformationFile to C:\Windows\System32\ntdll.dll with a result of SUCCESS. I have ProcMon logs from running normally (with the crash) and running Elevated (without the crash). I've tried to compare but there are thousands of entries and nothing really stands out as the cause.

  • Researched and used some debugging tools to collect more data including ProcMon, ProcDump and WinDbg. So far the only thing I've found here is the same kernelbase.dll exception info, but only codes are provided, no meaningful message. I had issues loading the symbols, but I think I figured that out. I'm new to WinDbg so I may not have it dialed in 100%. I couldn't get it to successfully load the CLR using .loadby sos clr. I had to use this work around to load SOS, using .load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll and even tried c:\windows\Microsoft.NET\Framework\v4.0.30319\clr.dll, but am still only getting coded exception info and no message in plain english. Here is what I get when using .excr in WinDbg after loading the dump file made using ProcDump

    eax=01fcf898 ebx=e0434f4d ecx=00000001 edx=00000000 esi=01fcf928 edi=022da1e0
eip=7453b802 esp=01fcf898 ebp=01fcf8f0 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
KERNELBASE!RaiseException+0x62:
7453b802 8b4c2454        mov     ecx,dword ptr [esp+54h] ss:002b:01fcf8ec=0911506f

  • I tried using !clrstk in WinDbg but it says "No export clrstk found"

Questions

To me it seems there is an unhandled CLR exception occurring prior to the app startup, probably because of some windows permissions conflicts either on a file or registry entry, but I don't know how to chase it any further.

  • How can I find out more info on the specific exception that's occurring? I couldn't find a list of Fault Offset codes for kernelbase.dll online.
  • What else can I check?
Paul Hitchcock
  • 73
  • 1
  • 6
  • Based on your description of your "Unhandled Exception" handler you are using VB's Application Framework provided event. It is my understanding that this only captures exceptions on the main UI thread. I recommend that you try the [AppDomain.UnhandledException Event](https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.110).aspx#Remarks). You should be able to continue using the Application FrameWork and wire up the `AppDomain.CurrentDomain.UnhandledException` in its `Startup` event handler. Doing this may allow you to capture some useful information. – TnTinMn Jul 27 '17 at 00:43
  • I tried this but no luck. I first tried adding AddHandlers to MyApplication.Startup event for AppDomain.UnhandledException and System.Windows.Forms.ThreadException. I got the same result. It doesn't appear that it runs any of the code in the Startup event. I proved this a few ways by adding some code at the begninning of the Startup event to give some feedback including a msgbox and a write to the event log. I also tried disabling the application framework and using a Main() sub instead and had the exact same result. It crashes before it runs any of the code in Main(). – Paul Hitchcock Jul 27 '17 at 07:16
  • Still banging my head against the wall on this one, and not getting any help on here or technet. I created a new local account with the same rights on the machine and created a ProcMon log and compared side-by-side with the log from the profile that is crashing. The first 60 or so lines are identical but then there is a big change. The broken profile starts doing a lot of referencing to apphelp.dll and referencing registry areas for AppCompatFlags. It's almost as if one profile thinks it needs to run in compatibility mode, and the other doesn't. The one that does is the one that crashes. – Paul Hitchcock Jul 29 '17 at 07:31

2 Answers2

2

I was able to fix this so the app started working again. After comparing two ProcMon logs side-by-side (one from the profile that was crashing, and one from a new profile with same rights) I found that on the profile that was crashing, it started very early referencing apphelp.dll and looking at AppCompatFlags keys in the registry. That led me to believe it was trying to run in compatibility mode, which it shouldn't need to do.

Even though the I made sure there was no compatibility mode set through the UI by right-clicking the app icon and viewing the properties, there were still some records stored in the registry. I removed entries for the app from the following keys and logged the user out and back in, and the issue has gone away. To be fair, I did a few other things as well that may have contributed. I downloaded and ran the .NET Repair Tool. It didn't solve the issue immediately after running it, but I thought I'd mention it just in case it played a part. I ran the repair kit first, then found and removed the registry entries, then logged the user out and back in.

Ultimately, I'm not really sure what caused this to occur in the first place, but from what I read, it's possible the app crashed once, and Windows tried to do some compatibility troubleshooting on it and stored some keys in the registry which ended up causing to crash consistently.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted
Paul Hitchcock
  • 73
  • 1
  • 6
0

In my case, the exception code led me to Exception code: 0xe0434f4d

As mentioned in the post, the trick was about .net framework version installed and supportedRuntime key in app.config.

Kevin Dimey
  • 709
  • 6
  • 15