程序在保护之后如果发生了崩溃，大家在排查的时候，不应该只盯着程序一打开就闪退这个表面现象；因为Obsidium这个工具本身是用来给32位和64位Windows程序做加密和授权的，在保护程序的时候，工具会处理入口、进行加密、压缩以及校验，还会加上反调试，这就导致程序启动时比没加密前要复杂得多。在下载页面上，该工具也分成了x86和x64两个版本，这说明我们在检查时，首先得看程序位数和工具是不是匹配。

　　一、Obsidium保护日志怎么看

　　我们在看Obsidium保护日志的时候，主要需要确认保护过程有没有顺利地跑完，因为这个日志并不是专门用来分析程序崩溃的报告；也就是说，通过这个日志，我们可以知道保护时的配置、输入和输出文件有没有出错，至于程序在运行的时候为什么会退出来，我们还是得配合Windows事件日志和Dump转储文件来一起分析。

　　1、看保护流程是否完整结束

　　我们在把保护文件生成出来以后，需要先去日志的最后面看一看，确认有没有写着成功完成或者输出文件已经写好这类的话；要是发现日志在中间就报错了，或者写着中断、文件写不进去、找不到目标文件这些提示，这时候大家就先别去测试这个保护后的程序了；因为此时程序打不开，大概率不是运行时候的问题，而是保护文件在生成的时候就没弄好。

　　2、看输入文件和输出文件是不是同一个版本

　　在保护日志里面，通常会把正在处理的目标文件路径，还有最后吐出来的文件位置都显示出来；这时候我们得特别留心两个地方，一个是Obsidium现在加密的到底是不是待发布的EXE或者DLL，另一个是我们在测试的时候，运行的到底是不是刚刚弄出来的那个文件；很多时候启动崩溃查到最后，才发现原因其实很简单，就是工具加密的是A目录里的文件，而测试人员点开的却是B目录里的旧文件，或者是打包时把上一版的文件放进去了。

　　3、看程序位数是否匹配

　　32位的程序和64位的程序是不能混在一起处理的；如果拿来打包的目标程序是32位的，我们就得换上对应的x86保护工具，如果目标程序是64位的，那就要用x64的保护工具；要是这两个位数没有对上，工具可能会直接报错提示失败，也可能勉强生成了但在运行的时候表现出各种不正常；这个地方虽然很基础，但是在很多个项目、很多个版本同时打包的时候，经常会被人忘掉。

　　二、Obsidium保护后崩溃原因怎么定位

　　我们在定位崩溃原因的时候，千万别图省事一口气把所有的加密和保护选项全部勾上；比较稳妥的办法，是顺着没有保护的版本、加了最少保护的版本、再到一项一项开保护这个顺序去慢慢试。

　　1、先测未保护程序

　　我们要先把最原始没加密的EXE或者DLL拿到同一台测试机上面去运行一下；要是发现连没加密的程序本身也会崩溃，那就得先去解决程序自己的毛病，比如是不是缺了运行库、配置文件写错了、插件路径不对、数据库没连上或者权限不够；在这个阶段，大家先别急着去乱改Obsidium里面的配置。

　　2、生成最小保护版本

　　我们可以先把压缩、字符串加密、代码虚拟化、反调试还有硬件锁定这些花哨的强化功能全部关掉，只留一个最底层的保护配置来生成一个文件；要是这个最基础的保护版本可以正常跑起来，那就说明基本的保护流程应该没啥大问题；如果发现连这个最低配的版本都崩溃了，那我们就得好好看看程序入口、自校验、运行目录还有读取文件的逻辑是不是冲突了。

　　3、逐项恢复保护功能

　　这时候我们要耐下心来，每次只把一个功能勾上，然后生成一个版本，再去测试一个版本；比如我们可以先试着把压缩打开，要是没问题，再把字符串加密勾上，接着去测反调试，最后去测代码虚拟化；如果是在开了某一个特定功能之后程序才死掉的，那问题的范围不就一下子缩小了吗；大家千万别偷懒一次性全打开，要不然最后只能得到一个很糊涂的结论，那就是程序保护完就崩了。

　　三、Obsidium保护后崩溃先看哪里

　　要是程序已经成功弄出来了，但是一运行就死掉，这时候就得去查运行环境了；Windows程序崩溃的时候，系统自带的事件查看器里会留下错误记录，里面会写明白故障应用程序、出问题的模块、异常代码还有偏移地址，这些数据可比一句简单的闪退管用多了；在官方的相关说明里也写过，排查应用崩溃的时候，经常要去应用程序日志里看那些Event ID是1000或者1001的报错记录。

　　1、打开【事件查看器】查看应用程序错误

　　我们可以先打开【事件查看器】，然后点进【Windows日志】里的【应用程序】，去里面翻一翻崩溃那个时间点前后的错误信息；我们要把注意力放在故障应用名、故障模块名、异常代码、故障偏移和路径上面；大家千万不要只截一张弹出来的错误提示框，因为那个框子里写的东西往往特别少，根本不够用。

　　2、判断故障模块是谁

　　如果最后查出来故障模块就是主程序EXE，那问题可能出在程序入口、自检的代码、保护初始化的地方，或者和授权读取、原程序本身的bug有关；如果显示故障模块是某个第三方的DLL，这时候就需要去排查插件、运行库、驱动或者图形库、数据库这些依赖项了；要是发现故障模块和.NET运行时有牵扯，那就得连同目标框架、运行时版本还有托管异常一块儿去翻翻，不能直接把它当成普通的底层程序崩溃来对付。

　　3、记录异常代码

　　这个异常代码是相当关键的；比方说0xc0000005这个代码，经常代表发生了访问冲突，这多半和内存怎么访问、插件怎么加载、有没有被Hook、自校验或者加密后的入口流程有关系；如果是别的非法指令、栈溢出或者是运行库报错，那我们查问题的方向就得换一换了；所以大家别只在记录里写启动崩溃，务必把这个异常代码也抄下来。

　　总结

　　总的来说，看Obsidium保护日志主要是为了确认保护过程完不完整、输入和输出的文件对不对、位数有没有配错，还有保护时有没有出警告；而程序保护后发生崩溃了，那就得去翻Windows事件查看器、看异常代码和故障模块，还得去查Dump文件。在排查的顺序上，我建议大家从未保护的程序开始入手，接着去生成一个最小保护的版本，然后再把压缩、字符串加密、反调试、代码虚拟化这些开关一个一个地打开。把这两件事分开来处理，我们就能把Obsidium保护日志怎么看、Obsidium保护后崩溃原因怎么定位这两个问题弄明白了，不至于把配置的错误、程序自己的bug和用户那边的环境问题全给和稀泥搅在了一起。