掃描應用程式以發現即修正其中的弱點是一個複雜的流程。包含了組建應用程式、分析程式碼和二進位碼以找出弱點、修正這些弱點，以及產生修正後安全的程式碼。
這個文章說明了掃描過程中各階段可能發生的問題，以及排除的方法。
分析準備中階段可能發生的問題
-
掃描停留在分析準備中階段的 40% 至 60% 間
若開啟相依性分析且 real-time intelligence 設為 basic 或 advanced，線上服務將被用來探索應用程式所使用的相依性。若掃描停留在分析準備中階段的 40% 至 60% 間相當長一段時間，線上服務可能發生問題。試著將 real-time intelligence 設為 off 或關閉相依性分析來看看掃描是否能前進。
-
掃描停留在分析準備中階段的 60% 至 90% 間
在分析應用程式前，Lucent Sky AVM 掃描程式碼檔案以及函式庫來了解應用程式的架構、規模，以及偵測程式碼檔案的編碼。如果應用程式有大量的程式碼，偵測程式碼的編碼可能會花費許多時間。如果所有的程式碼檔案都使用同樣的編碼，在掃描參數中指定其編碼（例如
Encoding,Utf8）可減少此階段需要的時間。
組建階段可能發生的問題
-
因為 Ant 錯誤導致掃描失敗
要解決 Ant 錯誤，請參考 Lucent Sky 知識庫：
排除 Ant 錯誤 -
因為 ASP.NET 編譯錯誤導致掃描失敗
要解決 ASP.NET 編譯錯誤，請參考 Lucent Sky 知識庫：
排除 ASP.NET 編譯錯誤 -
因為 Maven 錯誤導致掃描失敗
要解決 Maven 錯誤，請參考 Lucent Sky 知識庫：
排除 Maven 錯誤 -
因為 MSBuild 錯誤導致掃描失敗
要解決 MSBuild 錯誤，請參考 Lucent Sky 知識庫：
排除 MSBuild 錯誤 -
因為 IL 產生錯誤導致掃描失敗
出現 IL 產生錯誤時，依照掃描結果碼對應的解決方式來排除錯誤。要檢視所有掃描結果碼，請參考 Lucent Sky 知識庫：
Lucent Sky AVM 掃描結果碼 -
組建階段出現其他錯誤
應用程式可能是一個 Lucent Sky AVM 不支援的架構。要深入了解如何準備應用程式以進行掃描，請參考 Lucent Sky 知識庫：
準備應用程式以進行掃描
除了排除組建錯誤之外，另一個方式是使用直接二進位分析來掃描 .NET 和 Java 應用程式，而不需要在 Lucent Sky AVM 中組建它們。要深入了解如何使用直接二進位分析，請參考 Lucent Sky 知識庫：
使用直接二進位分析掃描應用程式
分析階段可能發生的錯誤
分析階段（S-1 至 S-5）出現錯誤時，依照掃描結果碼對應的解決方式來排除錯誤。要檢視所有掃描結果碼，請參考 Lucent Sky 知識庫：
Lucent Sky AVM 掃描結果碼
修正後程式碼的問題
-
組建修正後的程式碼時出現缺少的參考
Lucent Sky AVM 使用 Application Protection Library（APL）來修正某些弱點。如果專案沒有參考 APL，可能會發生組建錯誤。要深入了解如何在應用程式中使用 APL，請參考 Lucent Sky 知識庫：
在應用程式中使用 Application Protection Library -
組建修正後的程式碼出現語法錯誤
雖然極少見，將 Instant Fix 插入原始程式碼時可能會發生錯誤，導致編譯時的語法錯誤。
這些語法錯誤通常相當明顯。依照該語言的語法規則調整 Instant Fix 以排除語法錯誤。
-
組建修正後的程式碼時出現關於無效的位元組順序記號（BOM）的錯誤
Lucent Sky AVM 產生的修正後程式碼檔案使用原始檔案的編碼。唯一的例外是 UTF-8 檔案：當檔案的原始編碼是不使用 BOM 的 UTF-8 時，修正後的檔案會以使用 BOM 的 UTF-8 作為其編碼。有些編譯器要求 UTF-8 檔案必需不使用 BOM，且在遇到使用 BOM 的 UTF-8 檔案時會出現無效的位元組順序記號的錯誤。
要讓 CLEAR Engine 產生不使用 BOM 的 UTF-8 檔案，將 CLEAR Engine 設定檔案中
Utf8EmitBom的值改為false。 -
組建修正後的程式碼時出現關於無效字元的錯誤
無效字元的錯誤通常是因為不正確的編碼所贈成的。如果有使用掃描參數指定編碼，確認該編碼是正確的。
此外，CLEAR Engine 在修正後的程式碼檔案中使用 CRLF 分行符號。雖然大多數的組建工具和編譯器能正確處理不同的分行符號，有些工具僅接受和作業系統相同的分行符號。在類-Unix 系統上，使用 dos2unix、tr、sed 等命令將修正後的程式碼檔案的分行符號由
CR LF轉換為LF。