none
How can I determine the cause of an AppCrash on Unhandled Exception in Kernelbase.dll prior to Application Start? RRS feed

  • Question

  • 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. They are also arguing that Microsoft does not recommend this approach based on this article. 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 profiles that are affected.

    Application Info

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

    User Environment Info

    • There is a Domain server present, but not all of the PCs on the network are joined to the domain. One of the profiles affected is a local account logging into a Domain PC. The other profile affected is a local account logging into a non-Domain PC.
    • Domain PC is 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. There were some Windows updates as well as some updates to our software.
    • If we login in with a new user profile, or even some of the existing profiles, the issue does not occur. It seems to be isolated to only the two specific user profiles.

    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 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"
    • Have also tried adding Event Handlers for AppDomain.UnhandledException ans System.Windows.Forms.ThreadException from the Application.Startup Event.
    • Have also tried disabling Application Framework and using a Main() sub to load the same event handlers. The app crashes before the first line of the Main() or Application.Startup code is ran.

    Questions

    From what I've read 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/folder 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?

    Friday, July 28, 2017 5:23 PM

Answers

  • Thanks for the info, deathstarlaunch.

    I ended up finding the solution to this myself. I posted my answer on Stack Overflow which had a few more comments, and didn't want to rewrite the entire answer here, so here is the link to that post in case anybody is interested. Ultimately it ended up being some registry entries under HKCU that was causing the app to attempt to open using some compatibility mode settings. How those registry entries got there? Not sure, but after removing them the issue has gone away and the app is opening again without elevation.

    This issue introduced me to some new troubleshooting tools I wasn't familiar with, so there was a plus side to it. Using ProcMon to compare two logs side-by-side (I exported to CSV and used Excel) is what got me going in the right direction. Kudos to the Sysinternals team for the great tools!

    • Marked as answer by phitchcock78 Saturday, July 29, 2017 8:22 AM
    Saturday, July 29, 2017 8:22 AM

All replies

  • I would incline to along with permissions. On a similar note I had a developer install an application on a server, same issue kernalbase, fired up the app with amin permissions and it worked just fine.

    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    Friday, July 28, 2017 7:17 PM
    Moderator
  • Thanks for the input, Karen. Any ideas on how I can track down the offending permission?

    Running as admin permissions does work, but is not a feasible solution as it causes other issues down the line.

    Friday, July 28, 2017 9:42 PM
  • There are several pages (see this Google search) on setting up the app in the app manifest via app.config. Otherwise you would have the network admin set permissions for the user, usually through Active Directory. If there is more than one user the admin can setup a group and place those users into that group with proper permissions to run the app.

    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    Friday, July 28, 2017 10:31 PM
    Moderator
  • Did you mean to send me a search on how to run an app as an administrator?

    I think you misread my response and, correct me if I'm wrong, it doesn't really sound like you thoroughly read my original post. Running as administrator is not an option, running the app elevated causes other issues. I know the app will run as administrator, as is stated in the original post, but what I need is a way to stop it from crashing while not running it elevated.

    I'm trying to find a method to determine the root cause of the crash. I'm at a dead end on the exception thrown by the kernelbase.dll. I'm looking for a way to lookup the fault offset code for the exception raised to see if there is more info there to help determine the cause, but ultimately I'm just trying to figure out why it's crashing all of the sudden.

    The app was running fine under this account a month ago, now it's crashing, but only on two specific user profiles out of hundreds of customers PCs. The user profile that it started crashing on is a local account with local admin rights. If there was a policy turned on to block the app from running, there is a specific error message that pops up for that event. 

    Would it make sense to use ProcMon and walk through each step prior to the crash and check permissions on each item? It was over 2000 records so I haven't gone down that road yet. I was hoping somebody would respond who understood the process of troubleshooting items at this level, but am not getting many responses on here or on StackOverflow.

    The last line in ProcMon prior to the Process Exit is a call to ntdll.dll.  I don't know enough about ProcMon to know if it is likely that the last call prior to Process Exit has anything to do with the exception or if it's just a coincidence.

    Saturday, July 29, 2017 1:46 AM
  • 1.) Good description

    2.) Thanks for the hex dump

    3.) I am not great at VB, but I can read machine code

    The description that you provided of an intermittent problem is the result of a conflict.  The kernel is the part of the os that provides services to the applications.  It does things like fileio, screen writes, mouse & keyboard, etc.  Instead of every programmer having to write those, windows does it for you and you use a dll for these activities.

    The hex dump lists ecx [counter] as 1.  That means that something was opened or tried to open (such as a network resource or a local file).  I think that the problem is that a network resource is unavailable [this includes access denied] or in use.

    Alternatively, you may have a variable that is being treated as a constant 0/nul because it is declared, but not initialized.

    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.


    Simply, you can not.  The specific error that is occurring is not actually in the kernel.  The error has been passed down from a procedure.  Kernal.dll just knows to check if everything is ok, before it does anything.  

    KERNELBASE!RaiseException+0x62:  More likely than not this is the file that was trying to be opened (Note: a computer using TCP/IP treats network resources as files).

    KERNELBASE!RaiseException+0x62:7453b802 8b4c2454        

                                         mov     ecx,dword ptr [esp+54h]

                                              ss:002b:01fcf8ec=0911506f

    if it was JAVA, then you should implement a wait until resource is available at the start of the program.  

    and finally, avoid using constants in your VB code, instead use a text file to load the constants.  The constants are making the inevitable failure take forever?

    Saturday, July 29, 2017 6:34 AM
  • The last line in ProcMon prior to the Process Exit is a call to ntdll.dll.  I don't know enough about ProcMon to know if it is likely that the last call prior to Process Exit has anything to do with the exception or if it's just a coincidence.

    It is the cause of the exception if another thread starts, that is to use those same resources that process exit should release back to the resource pool.  It also sounds like a problem with network permissions.  What I mean by network permissions is: are all of the files that the program needs allowed under the network system policy?  If you copied the old permissions after the update...

    Saturday, July 29, 2017 6:45 AM
  • Thanks for the info, deathstarlaunch.

    I ended up finding the solution to this myself. I posted my answer on Stack Overflow which had a few more comments, and didn't want to rewrite the entire answer here, so here is the link to that post in case anybody is interested. Ultimately it ended up being some registry entries under HKCU that was causing the app to attempt to open using some compatibility mode settings. How those registry entries got there? Not sure, but after removing them the issue has gone away and the app is opening again without elevation.

    This issue introduced me to some new troubleshooting tools I wasn't familiar with, so there was a plus side to it. Using ProcMon to compare two logs side-by-side (I exported to CSV and used Excel) is what got me going in the right direction. Kudos to the Sysinternals team for the great tools!

    • Marked as answer by phitchcock78 Saturday, July 29, 2017 8:22 AM
    Saturday, July 29, 2017 8:22 AM
  • I am glad that you got it to work!  I have two questions, though.  1.)  What is compatibility mode?  and 2.)you said app - is this program for a mobile device?
    Tuesday, August 1, 2017 5:21 AM