从零实现游戏内存读写与自动化：基于Cheat Engine与C#的实战指南-育师

1. 项目概述：为什么我们要自己动手读写游戏内存？

几年前，我还在为一个简单的游戏自动化需求头疼——想写个脚本自动喝药，或者自动释放某个技能。市面上的“外挂”要么功能不合心意，要么捆绑一堆乱七八糟的东西，更别提安全风险了。后来接触到Cheat Engine（简称CE），这个神器让我第一次窥见了游戏运行时的“内存世界”，但它的操作终究是手动的。于是，一个念头冒了出来：能不能用C#把CE的手动操作自动化，写一个稳定、可控、功能定制的“小助手”？

这就是“从零开始：使用Cheat Engine和C#实现游戏内存读取与自动化操作”这个项目的由来。它不是一个教你制作破坏游戏平衡外挂的教程，而是一个深入理解Windows程序内存模型、进程间通信和自动化技术的绝佳实践。无论是想为单机游戏制作辅助工具提升体验，还是学习逆向工程、游戏安全、自动化测试，甚至理解操作系统如何管理内存，这个项目都能给你带来实实在在的收获。整个过程就像一场数字侦探游戏，你需要用CE作为“扫描仪”和“探测器”，找到关键数据在内存中的“门牌号”（地址），然后用C#编写“机器人”，按照这个地址去读取状态、写入指令，最终完成一系列自动化操作。

听起来很酷，但这条路坑不少。内存地址会变（指针寻址）、游戏有保护（反作弊）、代码写得不严谨会导致程序崩溃……这份“避坑指南”就是把我趟过的雷、总结的经验，系统地分享给你。我们会从最基础的原理讲起，手把手用CE定位一个游戏数值（比如生命值）的地址，然后逐步深入到用C#编写健壮的读写代码，处理多级指针，最终实现一个简单的“血量低于50%自动使用治疗药水”的自动化逻辑。只要你有一点C#基础和对技术的热情，就能跟着走完全程。

2. 核心原理与工具准备：理解内存这座“城市”

在开始写代码之前，我们必须先建立正确的认知模型。你可以把运行中的游戏进程所占用的内存，想象成一座庞大而结构复杂的城市。这座城市里的每一个数据——你的角色等级、金币数量、生命值、坐标位置——都住在一个个“房子”（内存地址）里。我们的目标，就是找到特定数据（比如“生命值”）的家，并时不时去拜访（读取）它，或者在必要时给它送点东西（写入）。

2.1 虚拟内存：进程的私有“城市沙盘”

现代操作系统（如Windows）使用“虚拟内存”机制为每个进程（如游戏）提供一个独立的、从零开始编址的虚拟地址空间。这意味着你的游戏进程以为自己独占了从0x00000000到0x7FFFFFFF（32位进程用户模式）的整个“城市”区域，而其他进程也有自己完全独立的“城市沙盘”。操作系统和CPU硬件负责将这些虚拟地址映射到实际的物理内存条上。对我们来说，好处是地址空间规整，且进程间互不干扰；挑战在于，我们无法直接使用物理地址，所有操作都必须基于目标进程的虚拟地址空间。

2.2 基址与偏移：在“城市”中定位“房间”

游戏启动时，操作系统会为它加载主模块（通常是.exe文件）和一系列动态链接库（.dll文件，如UnityPlayer.dll, GameAssembly.dll）。主模块加载的起始虚拟地址称为“模块基址”。然而，由于操作系统的地址空间布局随机化（ASLR）安全特性，这个基址每次启动游戏都可能不同。

那么，一个固定的游戏数据（如生命值）地址岂不是每次都在变？是的，它的“绝对地址”在变。但它在自己所属模块内部的“相对位置”是固定的。这就引出了“多级指针”的概念。

假设生命值数据存储在游戏逻辑模块（比如GameLogic.dll）中一个类的实例里。它的寻址路径可能长这样：GameLogic.dll基址 + 0x123456指向一个指针，这个指针的值是0xABC00000。0xABC00000 + 0x78指向另一个指针，其值是0xDEF00。0xDEF00 + 0xC这个地址，才最终存储着你的生命值。

这里的0x123456、0x78、0xC就是偏移。GameLogic.dll的基址每次启动会变，但通过“基址+偏移1”找到指针A，再“指针A+偏移2”找到指针B，最后“指针B+偏移3”找到数据，这条路径是稳定的。我们的任务就是用CE找到这条指针路径，然后在C#代码中动态计算最终的地址。

2.3 工具准备：我们的“侦察兵”与“工程队”

Cheat Engine 7.5/7.7：核心侦察工具。它就像一个强大的内存扫描仪和调试器，能快速扫描内存中变化的值，并帮我们分析指针路径。我们将用它来完成初期的地址定位和指针分析。建议从官网下载最新稳定版。
Visual Studio 2022：主力开发环境。社区版完全免费且功能强大。确保安装“.NET桌面开发”工作负载。
目标游戏：选择一个简单的单机游戏作为练习对象。强烈建议使用专门为学习修改而设计的游戏，如《Cheat Engine Tutorial》或《植物大战僵尸》经典版本。切勿在在线多人游戏上尝试，这违反用户协议且可能导致封号。
C# 项目类型：我们将创建一个“控制台应用”项目，这样更专注于逻辑本身。

注意：法律与道德边界本项目所有技术讨论及实践，严格限于单人模式、离线、或明确允许修改的单机游戏，以及自己拥有完全控制权的应用程序。未经授权对在线游戏、商业软件进行内存修改以获取不当利益，是明确违反法律和服务条款的行为。我们的目的是学习技术原理与实现，请务必在合法合规的范围内进行实践。

3. 实战第一步：使用Cheat Engine定位游戏数据

理论讲完，我们立刻动手。假设我们的目标是《植物大战僵尸》里的阳光值。

3.1 初始扫描与精确制导

启动游戏和CE：打开游戏，进入一个正在进行的关卡，记下当前的阳光值（比如50）。
附加进程：在CE中点击左上角的电脑图标，在进程列表里找到游戏的进程（如plantsvszombies.exe）并打开。
首次扫描：
- “数值类型”选择4字节（大多数游戏整数用4字节存储）。
- 在“数值”框输入你当前的阳光值50。
- 点击“首次扫描”。CE会扫描整个进程内存，列出所有值为50的地址，结果可能成千上万。
过滤地址：
- 回到游戏，通过种植物等方式让阳光值发生变化（比如变成25）。
- 在CE的“数值”框输入新值25，点击“再次扫描”。
- CE会在上次的结果中筛选出值变为25的地址。重复这个过程（改变值，再次扫描），直到列表里只剩下少数几个（理想情况是1-2个）地址。这些就是阳光值的候选地址。
验证与锁定：在地址列表里选中最可疑的那个（通常其“值”列会随游戏内数值实时变化），双击将其添加到下方的地址列表。然后右键该地址，选择“更改记录->数值”，手动输入一个数（如9999），切回游戏看看阳光是否变化。如果变了，恭喜你，找到了！

3.2 挖掘指针：找到数据的“固定住址”

直接找到的地址是“静态地址”，游戏重启后就会失效。我们需要找到指向它的指针。

找出是什么访问了这个地址：在CE地址列表里，右键你找到的阳光值地址，选择“找出是什么访问了这个地址”。CE会弹出一个空窗口。
触发访问：切回游戏，进行一个会读取或写入阳光值的操作（比如收集阳光）。CE的窗口会立即出现一行或多行汇编指令，显示了访问该地址的代码位置和指令。
分析指针：在出现的指令行上右键，选择“找出指令访问的地址”。通常，指令会是类似mov eax, [ebx+00005530]的形式。这里的[ebx+00005530]就是通过指针（存储在寄存器ebx中）加偏移（5530）来访问数据。CE的指针扫描工具能帮我们系统化地寻找这个ebx的来源。
使用指针扫描：
- 在CE主界面，菜单栏选择“工具->指针扫描”。
- 设置好范围（通常默认即可），点击“确定”开始扫描。这会花点时间，生成一个包含所有可能指向目标地址的指针链的文件（.ptr）。
- 扫描完成后，重启游戏（关键步骤！）。游戏重启后，阳光值的地址肯定变了。
- 再次用CE附加游戏，用步骤1-4的方法，再次找到新的阳光值地址（记为新地址A）。
- 回到指针扫描窗口，点击“指针扫描器”对话框的“重新扫描内存-更改地址”，输入新的地址A，并勾选“删除无效指针”。点击“确定”，列表中的指针数量会大幅减少。
- 重复“重启游戏->找新地址->重新扫描”这个过程2-3次。这是最关键的避坑点！经过多次重启验证后依然存活的指针链，才是真正稳定的“基址+偏移”路径。最终你可能会得到一条像"Game.exe"+0012A3BC, 30, C, 5560这样的指针链。这表示：最终地址 =Game.exe模块基址 + 12A3BC处存储的指针值 + 30 + C + 5560 这三个偏移。

实操心得：指针扫描的耐心指针扫描是整个过程里最需要耐心的一步。一次重启验证就确认的指针很可能不可靠。我吃过亏，写好的自动化工具第二天游戏一更新就失效了，就是因为指针验证不充分。务必进行至少三次重启验证，确保指针链在多次游戏启动后都能准确指向目标数据。稳定的指针链是后续所有自动化操作的地基，地基不稳，楼盖得再漂亮也会塌。

4. C#内存读写核心实现：打造我们的“自动化机器人”

有了稳定的指针路径，我们就可以用C#来编写自动化的“机器人”了。C#通过Windows API与目标进程交互，核心是ReadProcessMemory和WriteProcessMemory这两个函数。

4.1 封装一个健壮的内存操作类

我们不直接调用复杂的API，而是先封装一个工具类MemoryHelper。这个类将处理进程打开、权限获取、指针计算和读写等脏活累活。

using System; using System.ComponentModel; using System.Diagnostics; using System.Runtime.InteropServices; public class MemoryHelper { // 导入必要的Windows API [DllImport("kernel32.dll")] private static extern IntPtr OpenProcess(int dwDesiredAccess, bool bInheritHandle, int dwProcessId); [DllImport("kernel32.dll")] private static extern bool ReadProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer, int dwSize, out int lpNumberOfBytesRead); [DllImport("kernel32.dll")] private static extern bool WriteProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer, int dwSize, out int lpNumberOfBytesWritten); [DllImport("kernel32.dll")] private static extern bool CloseHandle(IntPtr hObject); // 进程访问权限标志 private const int PROCESS_VM_OPERATION = 0x0008; private const int PROCESS_VM_READ = 0x0010; private const int PROCESS_VM_WRITE = 0x0020; private const int PROCESS_QUERY_INFORMATION = 0x0400; private IntPtr _processHandle; private Process _targetProcess; /// <summary> /// 附加到目标进程 /// </summary> /// <param name="processName">进程名（不带.exe）</param> public bool AttachToProcess(string processName) { try { Process[] processes = Process.GetProcessesByName(processName); if (processes.Length == 0) { Console.WriteLine($"未找到进程: {processName}"); return false; } _targetProcess = processes[0]; // 取第一个实例 // 组合所需的访问权限 int accessFlags = PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_QUERY_INFORMATION; _processHandle = OpenProcess(accessFlags, false, _targetProcess.Id); if (_processHandle == IntPtr.Zero) { throw new Win32Exception(Marshal.GetLastWin32Error(), "打开进程失败，请尝试以管理员身份运行本程序。"); } Console.WriteLine($"成功附加到进程: {_targetProcess.ProcessName} (PID: {_targetProcess.Id})"); return true; } catch (Exception ex) { Console.WriteLine($"附加进程时发生错误: {ex.Message}"); return false; } } /// <summary> /// 读取多级指针指向的最终地址 /// </summary> /// <param name="moduleName">模块名（如"Game.exe"）</param> /// <param name="baseOffset">模块基址偏移</param> /// <param name="offsets">多级偏移数组</param> /// <returns>计算出的最终地址</returns> public IntPtr CalculateFinalAddress(string moduleName, int baseOffset, int[] offsets) { if (_processHandle == IntPtr.Zero) throw new InvalidOperationException("请先附加到目标进程。"); IntPtr baseAddress = IntPtr.Zero; // 获取模块基址 foreach (ProcessModule module in _targetProcess.Modules) { if (module.ModuleName.Equals(moduleName, StringComparison.OrdinalIgnoreCase)) { baseAddress = module.BaseAddress; break; } } if (baseAddress == IntPtr.Zero) throw new ArgumentException($"未找到模块: {moduleName}"); // 计算第一级地址：模块基址 + 基础偏移 IntPtr currentAddress = IntPtr.Add(baseAddress, baseOffset); // 逐级读取指针 for (int i = 0; i < offsets.Length; i++) { // 读取当前地址存储的指针值（4字节或8字节，取决于目标进程是32位还是64位） bool is64Bit = Is64BitProcess(_targetProcess); int pointerSize = is64Bit ? 8 : 4; byte[] buffer = new byte[pointerSize]; if (!ReadProcessMemory(_processHandle, currentAddress, buffer, pointerSize, out _)) { throw new Win32Exception(Marshal.GetLastWin32Error(), $"读取指针失败 at 0x{currentAddress.ToString("X")}"); } // 将字节数组转换为地址 long pointerValue; if (is64Bit) { pointerValue = BitConverter.ToInt64(buffer, 0); } else { pointerValue = BitConverter.ToInt32(buffer, 0); } // 如果这不是最后一级偏移，则当前地址更新为读取到的指针值 // 如果是最后一级，currentAddress就是最终的数据地址，但我们还需要加上最后一个偏移 if (i < offsets.Length - 1) { currentAddress = new IntPtr(pointerValue); } // 加上当前级的偏移 currentAddress = IntPtr.Add(currentAddress, offsets[i]); } return currentAddress; } /// <summary> /// 从指定地址读取一个4字节整数 /// </summary> public int ReadInt32(IntPtr address) { byte[] buffer = new byte[4]; if (ReadProcessMemory(_processHandle, address, buffer, 4, out int bytesRead) && bytesRead == 4) { return BitConverter.ToInt32(buffer, 0); } throw new Win32Exception(Marshal.GetLastWin32Error(), "读取内存失败"); } /// <summary> /// 向指定地址写入一个4字节整数 /// </summary> public void WriteInt32(IntPtr address, int value) { byte[] buffer = BitConverter.GetBytes(value); if (!WriteProcessMemory(_processHandle, address, buffer, 4, out int bytesWritten) || bytesWritten != 4) { throw new Win32Exception(Marshal.GetLastWin32Error(), "写入内存失败"); } Console.WriteLine($"已向地址 0x{address.ToString("X")} 写入值: {value}"); } // 辅助方法：判断进程是否为64位 private bool Is64BitProcess(Process process) { if (Environment.Is64BitOperatingSystem) { bool isWow64; // 需要调用 Kernel32 的 IsWow64Process [DllImport("kernel32.dll", SetLastError = true)] static extern bool IsWow64Process(IntPtr hProcess, out bool wow64Process); if (!IsWow64Process(process.Handle, out isWow64)) { throw new Win32Exception(Marshal.GetLastWin32Error()); } return !isWow64; // 如果在64位系统上不是Wow64进程，那就是64位进程 } return false; // 32位系统上只有32位进程 } /// <summary> /// 关闭进程句柄，释放资源 /// </summary> public void Detach() { if (_processHandle != IntPtr.Zero) { CloseHandle(_processHandle); _processHandle = IntPtr.Zero; Console.WriteLine("已从进程分离。"); } } }

这个MemoryHelper类提供了从附加进程、计算复杂指针地址到读写内存的完整功能。注意其中的CalculateFinalAddress方法，它完美实现了我们之前分析的多级指针寻址逻辑。

4.2 实现自动化逻辑：监控与响应

现在，我们结合找到的指针链，实现一个简单的自动化示例：当阳光值低于某个阈值时，自动“生产”阳光（通过写入内存）。

class Program { static void Main(string[] args) { var memory = new MemoryHelper(); try { // 1. 附加到游戏进程 (以植物大战僵尸为例) if (!memory.AttachToProcess("PlantsVsZombies")) { Console.WriteLine("无法附加到游戏进程，请确保游戏已运行。"); return; } // 2. 定义我们之前用CE找到的稳定指针链 // 假设最终指针链为：["PlantsVsZombies.exe"+003A9EC0] + 768 + 5560 string moduleName = "PlantsVsZombies.exe"; int baseOffset = 0x003A9EC0; // 模块基址偏移 int[] offsets = new int[] { 0x768, 0x5560 }; // 多级偏移 Console.WriteLine("开始监控阳光值... (按Q退出)"); // 3. 主监控循环 while (!(Console.KeyAvailable && Console.ReadKey(true).Key == ConsoleKey.Q)) { try { // 计算当前阳光值的动态地址 IntPtr sunAddress = memory.CalculateFinalAddress(moduleName, baseOffset, offsets); // 读取当前阳光值 int currentSun = memory.ReadInt32(sunAddress); Console.WriteLine($"当前阳光值: {currentSun} (地址: 0x{sunAddress.ToString("X")})"); // 4. 自动化逻辑：如果阳光少于50，则自动增加到200 int threshold = 50; int desiredSun = 200; if (currentSun < threshold) { Console.WriteLine($"阳光低于 {threshold}，自动补充至 {desiredSun}..."); memory.WriteInt32(sunAddress, desiredSun); // 写入后稍作停顿，避免过于频繁的写入 System.Threading.Thread.Sleep(1000); } // 每秒检查一次 System.Threading.Thread.Sleep(1000); } catch (Exception ex) { Console.WriteLine($"循环内发生错误: {ex.Message}"); // 发生错误时等待稍长时间再重试 System.Threading.Thread.Sleep(5000); } } } catch (Exception ex) { Console.WriteLine($"程序发生致命错误: {ex.Message}"); } finally { // 5. 清理资源 memory.Detach(); } Console.WriteLine("程序已退出。"); } }

这个简单的控制台程序展示了完整的流程：附加进程、通过指针链定位动态地址、循环读取状态、根据状态执行写入操作。你可以在此基础上扩展出更复杂的逻辑，比如监控多个数值、组合条件触发、模拟按键操作等。

5. 高级话题与深度避坑指南

掌握了基础读写，我们可以探讨一些更深入的话题和常见的“大坑”。

5.1 处理不同类型的数值

游戏内存中不止有4字节整数（Int32）。常见的还有：

单精度浮点数 (Float)：用于存储坐标、血量百分比等。读写时需要BitConverter.ToSingle()和BitConverter.GetBytes(float)。
双精度浮点数 (Double)：更高精度的浮点数。
字节 (Byte)和布尔值 (Bool)：常用于状态标志位。
字符串 (String)：通常是UTF-8或Unicode编码。读取时需要知道字符串的最大长度，并正确处理编码和终止符（\0）。
数组或结构体：需要知道每个元素的大小和整体布局，连续读取一片内存区域。

你需要根据CE中扫描时确定的“数值类型”来选择合适的读写方法。在C#中封装对应的ReadFloat,WriteFloat,ReadString等方法会大大提高代码的复用性。

5.2 应对游戏更新与地址失效

这是自动化工具最大的敌人。游戏更新后，代码编译的地址很可能发生变化，导致指针链失效。

特征码扫描 (Pattern Scan)：这是更高级、更稳定的定位方法。不依赖绝对地址，而是搜索一段独特的机器码字节序列（特征码），并计算目标数据相对于这段特征码的偏移。即使游戏更新，只要这段代码逻辑没变，特征码就依然有效。实现特征码扫描需要用到ReadProcessMemory读取大块内存，并在其中进行字节数组匹配。这超出了本文基础范围，但它是专业辅助工具必须掌握的技能。
指针链的冗余设计：尝试寻找多条指向同一数据的指针链。当一条失效时，可以尝试备用链。
配置化：将指针链的模块名、偏移等参数保存在外部配置文件（如JSON）中。当游戏更新时，你可以用CE快速找到新的偏移，只需更新配置文件，而无需重新编译程序。

5.3 稳定性与性能优化

异常处理：如示例代码所示，try-catch必须无处不在。网络波动、游戏卡顿、进程权限变化都可能导致单次读写失败。良好的异常处理能让你的程序在遇到错误时记录日志、等待重试，而不是直接崩溃。
读写频率：循环中的Sleep至关重要。无节制的频繁读写（比如每秒上千次）会显著增加游戏进程的CPU占用，可能导致游戏卡顿甚至被检测。根据实际需要调整间隔，通常100毫秒到1秒的间隔对于状态监控已经足够。
以管理员身份运行：在某些系统配置下，对高权限进程（如一些使用了反作弊系统的游戏）进行读写，需要你的工具也以管理员身份运行。否则OpenProcess会失败。
多线程考虑：如果你的自动化逻辑复杂（如同时监控血量、魔法、冷却，并管理多个技能释放队列），可以考虑使用多线程。但要注意，对同一内存地址的并发读写需要加锁（lock）来保证数据一致性，避免竞争条件。

5.4 绕过简单的反作弊检测

一些单机游戏也会有基础的内存保护。

代码修改 (Code Injection)：游戏可能会在关键数据被修改时调用检测函数。使用CE的调试功能或x64dbg等工具，可以分析并尝试绕过这些检测。例如，找到检测函数的开头，将其改为直接返回(ret)，或者修改检测条件的跳转指令。这属于更高级的逆向工程范畴，需要汇编语言和调试知识。
内存保护属性：游戏可能使用VirtualProtectAPI将关键内存页设置为只读（PAGE_READONLY）。在写入前，你需要先用VirtualProtectExAPI临时将其改为可读写（PAGE_READWRITE），写入后再改回去。
驱动级保护：一些强大的反作弊系统（如EAC, BattlEye）运行在内核层，会监控用户层的内存修改行为。对于这类保护，强烈建议你停止尝试。在内核层面对抗不仅技术难度极高，而且法律风险巨大。我们的学习应严格限定在没有强保护的单机环境。

6. 从内存操作到完整自动化：模拟按键与图像识别

单纯的内存修改有时不足以实现复杂自动化。例如，你想让角色自动走到某个位置，这可能需要修改坐标（内存），但也可能需要结合其他技术。

模拟输入 (Simulate Input)：使用SendInput或keybd_eventAPI来模拟键盘按键和鼠标点击，可以操作游戏菜单、释放技能（快捷键）。System.Windows.Forms.SendKeys在控制台应用里可能不太稳定，更推荐使用P/Invoke调用Windows API。
图像识别 (Image Recognition)：当无法通过内存获取某些状态时（比如屏幕上某个图标是否亮起），可以使用图像识别库（如OpenCV的.NET封装Emgu.CV，或者AForge.NET）来捕捉屏幕截图，并匹配预设的模板图像。这通常比内存读写开销更大，但更通用。
结合使用：一个健壮的自动化脚本往往是混合模式。例如，用内存读取监控血量和蓝量，用图像识别判断某个技能图标是否可用（冷却完毕），然后用模拟按键来施放技能。内存操作负责“感知”内部状态，图像识别负责“感知”UI状态，模拟输入负责“执行”动作。

7. 常见问题排查与调试技巧实录

即使按照指南操作，你也一定会遇到各种问题。下面是我踩过的一些坑和解决方法：

问题1：CE能找到地址，但我的C#程序读出来总是0或者错误的值。

可能原因1：进程位数不匹配。这是最常见的问题！如果你的游戏是64位的，但你的C#程序默认编译为“Any CPU”且在32位系统运行，或者你的指针计算逻辑只考虑了4字节指针，就会出错。务必使用Is64BitProcess方法判断，并动态决定指针大小（4或8字节）。
可能原因2：偏移顺序或计算错误。仔细核对CE中指针扫描器的结果。偏移数组的顺序是从第一级到第N级，确保没有遗漏或颠倒。在代码中打印出每一级计算出的中间地址，与CE中“手动添加指针”时显示的地址进行对比。
可能原因3：权限不足。确保你的程序以管理员身份运行。特别是对一些现代游戏或运行在受保护文件夹下的游戏。

问题2：写入成功（程序没报错），但游戏内数值没变化。

可能原因1：写入了错误的数据类型。游戏可能用浮点数存储血量，你却写入了整数。用CE确认数值的确切类型。
可能原因2：地址正确，但游戏有“校验和”或“双缓冲”。有些游戏会在多个地方存储同一数据的副本，或者会在接受修改后重新计算并覆盖你的写入。你需要找到真正生效的那个地址，或者找到并修改控制写入的代码（高级逆向）。
可能原因3：反作弊干扰。游戏可能检测到内存被异常修改，立即将其修复。尝试在写入后极短时间内连续读取，看数值是否被改回。

问题3：程序运行一段时间后突然崩溃，或无法再读取到数据。

可能原因1：游戏崩溃或重启了。你的程序应该检测目标进程是否存在。可以在循环开始时检查_targetProcess.HasExited。
可能原因2：内存地址失效了。游戏切换场景、加载新地图后，数据可能被移动到新的内存区域。对于这类动态数据，你需要寻找更稳定的指针，或者实现“重新搜索”的逻辑（例如，定期用特征码重新定位基址）。
可能原因3：资源泄漏。确保OpenProcess打开的句柄最终被CloseHandle关闭。示例代码中的Detach方法和finally块就是为了处理这个。

调试技巧：

大量使用日志：在每一个关键步骤（附加进程、计算出的每一级地址、读取的值、写入的值）都输出到控制台或日志文件。这是定位问题最直接的方法。
与CE实时对比：让你的程序和CE同时附加到游戏。在代码中计算出最终地址后，将其打印出来（十六进制格式），然后在CE的地址列表中手动添加这个地址，观察两边读取的值是否一致。这是验证指针计算是否正确的黄金标准。
简化测试：先不要写复杂的自动化循环。写一个简单的测试程序，只做一件事：附加进程，计算地址，读一次值，打印出来。确保这个基础功能稳定后再添加复杂逻辑。

走到这里，你已经掌握了从窥探内存到构建自动化工具的核心流程。这条路从好奇开始，用CE作为钥匙打开了一扇门，门后是操作系统、编译原理、软件安全的广阔世界。每一个坑踩下去都很疼，但爬出来时带来的理解深度，是任何教科书都无法给予的。记住，能力越大，责任越大。将这些技术用于学习、研究和提升单机游戏体验，它们就是有趣的玩具和强大的工具；一旦越界，就可能变成麻烦的源头。保持好奇，保持敬畏，在合法合规的沙盒里尽情构建你的自动化世界吧。如果遇到解决不了的问题，不妨回到起点，用CE重新扫描分析，很多时候，答案就藏在最基础的字节变化里。