logo标签列表

如何在应用程序启动之前确定Kernelbase.dll中未处理异常引起的AppCrash原因？

vb.netclrcrash
4
应用程序在启动时崩溃，事件日志中的应用程序错误提供了以下信息:
故障模块名称: KERNELBASE.dll，版本: 6.2.15063.483，时间戳: 0xc3955624
异常代码: 0xe0434f4d
故障偏移量: 0x000eb802
背景故事如下：
在我们某个客户的网络中，我们的应用程序甚至无法打开就崩溃了。我已经花了几天的时间寻找答案，但还没有能够解决这个问题。我从一些基本的故障排除开始，发现没有找到任何罪魁祸首，但发现新用户配置文件可以解决问题，所以建议使用新的用户配置文件来恢复正常运行。他们外包的IT人员起初同意了，但在迁移用户数据到新的配置文件时遇到了困难，并且从未能够完成将受影响的用户迁移到新的配置文件中。现在这个问题出现在他们网络中的另一台机器上，他们正在反驳说问题出在我们的应用程序身上，我们应该花时间修复它。如果是我们的代码出了问题，我同意要修复它，但目前似乎还没有运行到我们的代码。而且，我们在除了这个网络以外的其他地方没有看到过这种问题，只有使用本地帐户登录域PC的两个帐户会出现此问题。
应用程序信息：
VB.NET Windows窗体应用程序，目标为.NET 4.5
是的，在ApplicationEvents.vb文件中存在一个UnhandledException的Application Event handler。
用户环境信息：
域网络，使用非域本地帐户在域PC上登录，本地管理员帐户类型。受影响的这两个用户都是使用本地帐户登录。迄今为止，这并不会影响任何使用域帐户登录的人。
编辑:更正，第二台发生故障的PC实际上没有加入域。
工作站运行Windows 10 Pro v1703，并更新至最新版本
如果以提升权限运行，则应用程序可以正常启动，但这会在后面引起其他问题，所以让他们始终以管理员身份运行是不可接受的解决方案。
应用程序在更新前一直在此PC上正常运行。
如果我们使用全新的域或非域帐户（无论是否具有本地管理员权限）登录，则不会出现此问题。它似乎只与看到这些问题的特定用户配置文件相关。
到目前为止的故障排除内容如下：
  • 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"

问题

在应用启动之前，似乎出现了一个未处理的CLR异常，可能是由于某个文件或注册表项上的一些Windows权限冲突引起的，但我不知道如何进一步跟踪它。

  • 如何查找有关发生的特定异常的更多信息？我在网上找不到kernelbase.dll的故障偏移代码列表。
  • 还有什么其他检查方法？
根据您对“未处理异常”处理程序的描述，您正在使用VB提供的应用程序框架事件。 我理解这仅捕获主UI线程上的异常。 我建议您尝试AppDomain.UnhandledException事件。 您应该能够继续使用Application FrameWork并在其“启动”事件处理程序中连接AppDomain.CurrentDomain.UnhandledException。 这样做可能允许您捕获一些有用的信息。 - TnTinMn
我尝试过了，但没有成功。我首先尝试将AddHandlers添加到MyApplication.Startup事件中的AppDomain.UnhandledException和System.Windows.Forms.ThreadException。我得到了相同的结果。它似乎没有运行Startup事件中的任何代码。我通过几种方式证明了这一点，包括在Startup事件的开头添加一些反馈代码，包括一个msgbox和一个写入事件日志。我还尝试禁用应用程序框架并改用Main()子，但结果完全相同。它在运行Main()中的任何代码之前崩溃。 - Paul Hitchcock
我还在为这个问题苦苦挣扎，但在这里或技术论坛上都没有得到任何帮助。我在机器上创建了一个具有相同权限的新本地帐户，并创建了一个 ProcMon 日志，并与崩溃的配置文件的日志进行了逐行比较。前60行左右是相同的，但之后有一个很大的变化。损坏的配置文件开始大量引用 apphelp.dll 并引用 AppCompatFlags 的注册表区域。就好像一个配置文件认为它需要在兼容模式下运行，而另一个则不需要。那个需要的就是会崩溃的那个。 - Paul Hitchcock
2个回答
2
我已经成功修复了这个问题，所以应用程序又开始工作了。通过将两个 ProcMon 日志并排比较（一个来自崩溃的配置文件，另一个来自具有相同权限的新配置文件），我发现在崩溃的配置文件中，它非常早就引用了 apphelp.dll 并查看了注册表中的 AppCompatFlags 键。这让我相信它正在尝试以兼容模式运行，但实际上它不需要这样做。

尽管我通过右键单击应用程序图标并查看属性，确保没有设置兼容模式，但仍然在注册表中存储了一些记录。我从以下键中删除了应用程序条目，并注销并重新登录用户，问题已经消失了。公平地说，我还做了其他一些可能有所贡献的事情。我下载并运行了 .NET 修复工具。虽然在运行后它并没有立即解决问题，但我想提一下它，以防它起了一定的作用。我首先运行了修复工具，然后找到并删除了注册表条目，最后注销并重新登录了用户。

最终，我并不确定是什么原因导致这种情况发生，但从我所读的内容来看，可能是应用程序曾经崩溃过一次，然后Windows尝试对其进行一些兼容性故障排除，并在注册表中存储了一些键，最终导致它持续崩溃。
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted
0
在我的情况下，异常代码引导我到异常代码：0xe0434f4d。
如帖子中所述，诀窍在于安装的 .net framework 版本和 app.config 中 supportedRuntime 键。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接