2017-07-26 31 views
0

應用是在事件日誌中的啓動和應用程序錯誤崩潰提供了以下信息:
錯誤模塊名稱:KERNELBASE.dll,版本:6.2.15063.483,時間戳:0xc3955624
異常代碼:0xe0434f4d
故障偏移:0x000eb802
如何在應用程序啓動之前確定Kernelbase.dll中未處理異常的AppCrash的原因?

這裏是後面的故事
在我們客戶的網絡之一,我們的應用程序崩潰之前,甚至可以打開。我現在花了幾天的時間尋找答案,但還沒有能夠解決這個問題。我從一些基本的故障排除開始,在找不到任何吸菸槍,但發現新的用戶配置文件解決了問題後,我建議這是一個很好的修復方法,可以重新啓動並重新運行。他們的IT外包IT首先同意,但將用戶數據遷移到新配置文件時遇到困難,並且無法完成將受影響的用戶遷移到新配置文件的任務。現在,問題發生在他們網絡中的另一臺計算機上,他們推遲說明問題出在我們的應用程序上,我們應該花時間修復它。我同意,如果它在我們的代碼中,我們應該修正它,但到目前爲止,它似乎甚至不足以達到我們的代碼。另外,除了在這個網絡中的其他地方,我們還沒有看到這個地方,這兩個帳戶都使用本地帳戶登錄到域PC。

應用信息

  • VB.NET Windows窗體應用程序,針對.NET 4.5
  • 是的,有在ApplicationEvents.vb的文件的應用程序事件處置存在UnhandledException。

用戶環境信息

  • 域網絡,域PC上,而是記錄在與本地管理員帳戶類型非域本地帳戶。這影響到的兩個用戶都使用本地帳戶登錄。到目前爲止,這不會影響任何人使用域帳戶登錄。
    編輯:更正,這是發生在第二臺PC實際上沒有加入到域。
  • 工作站運行與更新當前的Windows 10專業版v1703如果跑高架
  • 應用程序啓動時正常,但後來這會導致這樣讓他們始終以管理員身份運行不是一個可接受的解決方案等問題。
  • 應用程序在這臺PC上運行良好,直到最近更新。
  • 如果我們使用具有或不具有本地管理員權限的新域或非域帳戶登錄,則不會發生此問題。這似乎是隻與特定的用戶配置文件在看到問題

故障排除迄今

  • 閱讀幾十個帖子在網上處理kernelbase的。DLL崩潰,無法找到一個有這樣的工作
  • 卸載並重新安裝應用程序
  • 卸載,使用添加/刪除Windows組件重新安裝.NET修復
  • 增加了一些在Application.Startup事件事件日誌條目以及啓動屏幕和啓動表單上的Load事件,以查看我們是否得到了那麼多。在工作站進行測試,記錄成功。在受影響的機器上,不會發生日誌記錄,所以看起來甚至在Application.Startup事件之前發生崩潰。
  • 用於將procmon監控應用而墜毀,並在進程退出之前的最後一行是操作QueryNameInformationFileC:\ WINDOWS \ SYSTEM32 \ ntdll.dll中SUCCESS的結果。我有ProcMon日誌從正常運行(與崩潰)和運行高架(沒有崩潰)。我試圖比較,但有成千上萬的條目,並沒有真正突出的原因。

  • 研究並使用了一些調試工具來收集更多數據,包括ProcMon,ProcDump和WinDbg。到目前爲止,我在這裏找到的唯一一件事情是kernelbase.dll異常信息,但只提供了代碼,沒有任何有意義的消息。加載符號時遇到了問題,但我想我已經明白了。我是WinDbg的新手,所以我可能沒有100%撥打它。我無法使用.loadby sos clr成功加載CLR。我必須使用此工作來加載SOS,使用。加載C:\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ SOS.dll甚至試過c:\ windows \ Microsoft.NET \ Framework \ v4 .0.30319 \ clr.dll,但我仍然只獲取編碼的異常信息,並且沒有純英文的消息。以下是我在WinDbg中使用.excr時得到加載轉儲文件後,使用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 
    
  • 搞得我試着用在WinDbg中!clrstk但它說「沒有出口clrstk發現」

問題

對我來說,似乎有一個未處理的CLR異常發生在應用程序啓動之前,可能是因爲一些文件或註冊表項的Windows權限衝突,但我不知道如何追逐它更進一步。

  • 如何才能找到有關正在發生的特定異常的更多信息?我無法在線找到kernelbase.dll的Fault Offset代碼列表。
  • 我還能檢查什麼?
+0

根據您對「未處理異常」處理程序的描述,您正在使用VB的Application Framework提供的事件。我的理解是,這隻能捕獲主UI線程上的異常。我建議您嘗試[AppDomain.UnhandledException事件](https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v = vs.110).aspx#Remarks)。您應該能夠繼續使用Application FrameWork,並在其「Startup」事件處理程序中連接「AppDomain.CurrentDomain.UnhandledException」。這樣做可能會讓您獲取一些有用的信息。 – TnTinMn

+0

我試過這個,但沒有運氣。我首先嚐試將AddHandlers添加到AppDomain.UnhandledException和System.Windows.Forms.ThreadException的MyApplication.Startup事件中。我得到了同樣的結果。它似乎沒有運行啓動事件中的任何代碼。我通過在啓動事件啓動時添加一些代碼來證明了這一點,以提供一些反饋,包括msgbox和寫入事件日誌。我也嘗試禁用應用程序框架,並使用Main()子來代替,並得到完全相同的結果。它在運行Main()中的任何代碼之前崩潰。 –

+0

仍然把我的頭靠在牆上,並沒有得到任何幫助,在這裏或technet。我在機器上創建了一個具有相同權限的新本地帳戶,並創建了一個ProcMon日誌,並與崩潰配置文件中的日誌並排比較。前60條左右的線條是相同的,但後來發生了很大的變化。破損的配置文件開始對apphelp.dll進行大量引用,並引用AppCompatFlags的註冊表區域。這幾乎就像一個配置文件認爲它需要以兼容模式運行,而另一個則不然。那個是崩潰的那個。 –

回答

0

我能夠解決這個問題,所以應用程序再次開始工作。在比較兩個ProcMon日誌並排(一個來自崩潰的配置文件,一個來自具有相同權限的新配置文件)後,我發現在崩潰的配置文件中,它很早就開始引用apphelp.dll並查看AppCompatFlags鍵在註冊表中。這導致我相信它試圖以兼容模式運行,而不應該這樣做。

儘管我確認沒有通過右鍵單擊應用程序圖標並查看屬性在UI中設置的兼容模式,但仍有一些記錄存儲在註冊表中。我從下面的鍵中刪除了應用程序的條目,並將用戶登出並重新登錄,問題消失了。公平地說,我還做了其他一些可能起作用的事情。我下載並運行了.NET Repair Tool。它運行後沒有立即解決問題,但我想我會提及它,以防萬一它起作用。我首先運行了修復工具包,然後找到並刪除了註冊表項,然後將用戶註銷並重新登錄。

最終,我不確定是什麼導致了這種情況發生在第一位,但從我閱讀時,應用程序可能會崩潰一次,並且Windows試圖對其進行一些兼容性故障排除,並在註冊表中存儲了一些密鑰,最終導致一致崩潰。

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

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted 
相關問題