不知道哪一次更新，也不知道因為更新了什么，PC 上的 IGV 突然就不能用了。除了換一臺 Mac 以外還能怎么辦。下文記錄了 debug 的過程以及一點思考。

前奏

IGV 這個工具因為是 Java 全平臺適配的，一般不太容易出現 bug。在 Windows 上常見的問題是由于 Java 32位和64位版本問題造成的。在 64 位的電腦上安裝了 32 位的 Java(通常默認就是32位)后，如果給 IGV 分配的內存超過了 2G，就會報內存錯誤，直接體現為 igb.bat 點擊后無法打開。最直接的方法就是把 Java 升級到64位。

然而，不知道是哪一次更新，不知道是因為更新了什么，我的 bug 表現是 IGV 可以正常啟動但啟動后只要進行任意的一次點擊就會閃退。最初我的猜測是因為某一個內容的更新，導致了Java，Windows 和 IGV 三者不兼容。于是我分別更新了最新版的 IGV 和最新版的 Java，然后還升級過一次電腦系統，問題都沒有得到解決。當時時間有限，debug 的最直接方式就是繞開 bug。

替代方案

必須要用的軟件突然不能用了又急著用，立刻買個 Mac 就可以避免 Windows 上的問題，雖然錢不是問題，但問題是沒錢，所以只能尋找其它替代方案。因為 Java 本身是全平臺通用的，所以在服務器上下載了 IGV linux 版本，然后通過 Xming 在本地電腦上調用 Linux 開啟的 IGV 圖形操作界面。

這個方法解決了燃眉之急，但是從服務器通過 Xming 在本地進行點選，很多操作會用明顯的卡頓和延遲而且分辨率很低。并非長久之計。

dubug 過程

首先需要看一下相關 IGV 報錯信息

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffe51899e54, pid=8364, tid=0x0000000000004590

JRE version: Java(TM) SE Runtime Environment (8.0_191-b12) (build 1.8.0_191-b12)

Java VM: Java HotSpot(TM) 64-Bit Server VM (25.191-b12 mixed mode windows-amd64 compressed oops)

Problematic frame:

C ?[atig6pxx.dll+0x9e54]

Failed to write core dump. Minidumps are not enabled by default on client versions of Windows

If you would like to submit a bug report, please visit:

? http://bugreport.Java.com/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

閱讀報錯信息

因為我本身不懂 Java，只能根據報錯提取自己認為關鍵的內容進行檢索。

從以往的經驗來看，首先要重點關注哪里失敗或者不能啟動。在 log 文件 header 部分恰好出現了一句話「Failed to write core dump. Minidumps are not enabled by default on client versions of Windows」，這個信息看起來非常關鍵，很可能是因為 Windows 不可以寫入 core dump 導致的問題，那么自然應該首先開啟 core dump 試試。

在 SO 上查到了 core dump 的開啟方式，對于Java 8 使用 -XX:+CreateMinidumpOnCrash 參數即可。修改 igv.bat 文件再命令行里添加該參數后重新運行，問題依舊存在，只不過這次除了會生成 log 文件以外，還會生成一個大小幾 G 的 core dump 文件。看來這個問題并不是 IGV 閃退的原因。

在檢索的過程中，有中文帖記錄出現這樣的問題是因為「JRE version 和 JDK 不一樣」。所以重新下載一個版本對應的 JDK 或者 JRE 就可以解決。雖然我一開始其實也分不清他來有什么區別，也不確定自己是不是同時裝了這兩個東西，但是抱著試試又不會掛的心態，還是再一次卸載了電腦里的Java。

因為擔心是之前 Java 升級有問題，我還專門下載了官方的Java 卸載工具，想把自己電腦里所有和 Java 相關的東西都卸載個干干凈凈，重新來過。

按照 IGV 網站上給的 Java 8 下載鏈接，我又一次重新安裝了 Java，運行之后真的還沒有出現閃退的情況，因為根本就打不開了。其實這就是上文提到的因為 IGV 網站上的 Java 下載鏈接引導我下載了 32 位 Java 版本，但是 IGV.bat 中使用的內存配置是4G，超過了限額地緣故。我又不得不再一次卸載 32 位重新安裝了 64 位Java，閃退問題依舊存在。

不過，至此我確認了電腦不存在所謂的「JRE和JDK版本不一致的問題」，版本信息如下：

# JRE version: Java(TM) SE Runtime Environment (8.0_191-b12) (build 1.8.0_191-b12)

# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.191-b12 mixed mode windows-amd64 compressed oops)

控制變量

Debug 一個非常重要的經驗是需要 控制變量。如果有條件，不妨找一臺能夠正確運行某個程序的機器，看看它和自己報錯的機器有什么差別。

為此，我分別查看其他人幾臺可以正確運行 IGV 的 PC，發現有人的IGV版本較低，有人的 Java 版本較低，但是大家都可以正常使用，于是我又分別測試了幾個低版本的 Java 或者 IGV，然并卵。考慮自己的筆記本系統和軟件版本與我的工作 PC 高度一致，又用最新版的 IGV 和 Java 8 在筆記本上進行了測試，神奇的是在筆記本卻可以正常運行。

至此，我基本懵逼。因為Windows 系統和 IGV 版本以及 Java 版本完全一致的情況下，筆記本可以正常運行IGV，但是 PC 卻不可以。這里面一定有某些不可告人的力量。

理解報錯信息

通過上面幾步折騰，問題的關鍵應該不在于解決 「Failed to write core dump」而是需要再向前回溯，這個時候就要理解 Java 生成的log文件究竟傳達了哪些信息。

通常只有嚴重的錯誤引起Java進程非正常退出，出現了Crash，才會產生一個文件名為err+pid number 的日志文件。

檢索后發現很多 Java 的報錯都會出現 EXCEPTION_ACCESS_VIOLATION(0xc0000005)這一句話，他意味著Java 應用 Crash 時正在運行 JVM 自己的代碼，而不是外部的 Java 代碼。在這個位置還可能出現 SIGSEGV(0xb)或者 EXCEPTION_STACK_OVERFLOW這樣的內容。

再往下看另一個重要信息點是

Problematic frame:

C ?[atig6pxx.dll+0x9e54]

這里的信息是顯示 Crash 時 JVM 正在從哪個庫文件執行代碼。我遇到問題是 C，還可能是 V 和 J 等等。他們的意思如下

FrameType Description：

C: Native C frame

j: Interpreted Java frame

V: VMframe

v: VMgenerated stub frame

J: Other frame types, including compiled Java frames

接下來我又閱讀了一下 Java 的 debug 指南，里面的分析思路都是要看 C 后面提示了什么信息，然后給了一些 debug 的建議：

The first step to solving a crash in a native library is to investigate the source of the native library where the crash occurred.

• If the native library is provided by your application, then investigate the source code of your native library. A significant number of issues with JNI code can be identified by running the application with the?-Xcheck:jni?option added to the command line. See?The -Xcheck:jni Option.

• If the native library has been provided by another vendor and is used by your application, then file a bug report against this third-party application and provide the fatal error log information.

• If the native library where the crash occurred is part of the Java Runtime Environment (JRE) (for example awt.dll, net.dll, and so forth), then it is possible that you have encountered a library or API bug. If so, gather as much data as possible and submit a bug or report, indicating the library name. You can find JRE libraries in the jre/lib or jre/bin directories of the JRE distribution. See?Submit a Bug Report.

仔細閱讀之后發現基本沒讀出啥東西，但是現在從報錯信息中我已經明確了問題應該指向 atig6pxx.dll。

指果所因

既然定位到了atig6pxx.dll ，就要查查它是什么，搜索 atig6pxx.dll windows10在前面幾條結果中，我看到了這樣幾個信息

AMD Graphics Driver not working/incompatible with Win 10 Technical Preview

OpenGl for crimson drivers

如此看來，這個 atig6pxx.dll 和AMD 的顯卡驅動有關，而我的兩個顯示器之一顯卡確實是AMD的，從查詢結果來看，AMD 顯卡驅動的這個 atig6pxx.dll 和某些 win10 版本搭配在一起就存在問題(我用的就是有問題的版本？)。

接下來再試試 atig6pxx.dllJava的搜索結果，真還搜到了相關的一個帖子，官方給的回復大意是要發帖子的人詳細確定顯卡和升級之類的各種信息，看來這個問題確實是 Java 和 PC 的顯卡驅動有 bug。同時又聯想到我的控制變量實驗，筆記本是NVIDIA顯卡而不是AMD，進一步相信問題可能真出自 AMD 顯卡上。

解決問題

確定了bug的原因，接下來就要考慮如何解決問題。

首先需要知道 Java 和顯卡驅動是怎么能聯系到一起的，檢索一下 Javagraphics找到了 官網的一些說明。 這里主要涉及 Java 2D 這么一個東西，在搜索的過程中又找到了 Java 2D 的一些選項。在檢索的過程中，還從 SO 看到了一個稍微相關的帖子，其中一個建議也是對顯卡進行一系列的測試，其中提到了參數 -Dsun.Java2d.d3d=false。這里的參數和Java 2D 的參數吻合而且有一點眼熟，看到這里就要回過頭重新看看 igv.bat 文件。

官方提供的 igv.bat 實際命令如下

::Get the current batch file's short path

for %%x in (%0) do set BatchPath=%%~dpsx

for %%x in (%BatchPath%) do set BatchPath=%%~dpsx

Java -Xmx4g -Dproduction=true -DJava.net.preferIPv4Stack=true -Dsun.Java2d.noddraw=true -jar %BatchPath%\lib\IGV.jar ?%*

仔細看一下，官方這條命令實際調用的程序來自 lib 目錄的 igv.jar，只不過添加了幾個平時自己根本不會在意的參數，其中 -Dsun.Java2d.noddraw=true和之前 SO 中建議添加的參數非常類似，而這個參數又是一個和顯示性能相關的參數。隱約感覺問題就出在這里。

繼續貫徹控制變量的思想，首先不加任何參數在 lib 目錄下直接運行 igv.jar，嗯，真的沒有閃退。回到 bat 依次修改上面三個參數進行測試，直到我把 -Dsun.Java2d.noddraw=true 改為 false 后，bug 消失，至此問題解決。

復盤與反思

綜上，通過學習 log 文件，查找關鍵內容，控制變量測試，一步一步把 Java 的運行錯誤和顯卡聯系起來。不過我是萬萬沒想到這錯誤竟然是和顯卡相關。

進一步了解下Dsun.Java2d.noddraw這個參數的作用

The following list describes some useful properties on Windows platforms.

• The DirectDraw/GDI pipeline is the default pipeline for Windows. Change this default as follows:

• -Dsun.Java2d.noddraw=true?Disable the use of DirectDraw pipeline. GDI will be used instead.

• -Dsun.Java2d.noddraw=false?Enable the use of DirectDraw pipeline.

• -Dsun.Java2d.d3d=false?Disable the use of Direct3D pipeline.

也就是說，因為AMD 顯卡驅動中 atig6pxx.dll的問題，我目前的電腦并不能只使用 GDI 來進行渲染，而是必須要開啟 DirectDraw。至于更深次的原因暫時沒有深究的必要。

回顧整個 debug 的過程，雖然一直在嘗試使用控制變量的思路，但是具體的測試順序不對。

使用別人的電腦來控制變量，不相關的因素太多，各種軟件版本的不一致只是表象，并沒有指明到是真正的顯卡差別；而使用自己的筆記本和臺式機做比較，才排除了軟件版本的關系。

最后進行的控測試才是變量最可控的，應該首先就進行的在同一個電腦上對同樣的軟件進行不同的操作。其中一個操作是官方并不推薦的直接運行 lib 中的 igv.jar 程序，另一個操作是運行官方推薦的添加了參數的 igv.bat 。如果把這個測試提到第一步來做，就會節省大量的測試時間。

最后，對于 debug 的思考：

• 仔細閱讀報錯信息確定關鍵詞

  成熟的工具一定有著非常詳細的報錯信息，而我們要做的是從詳細的報錯信息中提煉關鍵詞進行檢索

• 按照從小到大的順序盡量找到可以正確運行的方式

  想要找到問題所在很關鍵的一點知道誰或者在哪里可以成功。這一步對之后的 debug 過程十分重要。

  所謂從小到大的意思是正確運行和錯誤運行之間的差異從小到大。最好可以在一臺電腦上完成，只是改變運行方式或者參數；如果不行就找配置盡量類似的電腦或服務器進行測試，以此類推。如果我首先能想到拋棄官方的建議打開方式去運行 jar 程序，直接就可以鎖定參數問題。

• 控制變量是進行測試應該遵循的首要思路

  通過檢索，我們可以找到大量的相關信息，可能會存在各種五花八門的解決方法。如何判斷哪些值得嘗試哪些不值得嘗試非常重要。對于本文的 bug，即便檢索到了很多關于軟件版本的問題，只要我在版本相同的另一臺電腦運行成功，那么所有和 Java 版本，Windows 版本以及 IGV 版本相關的內容都可以忽略掉，就省去了多次卸載安裝這樣的無用功。同時根據檢索信息再結合控制變量的思想就更加容易鎖定問題，進而找到解決方式。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的java报错怎么看_IGV 哐当就不能用了，除了换台电脑还能怎么办？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。