[附录：由于我的部分不正确的假设，问题不需要回答;请看下面的答案，以及我的论述]
我的客户端向我发送了一个客户发送的跟踪文件，其中包含（相关）仅在抛出异常时_CONTEXT结构中包含的CPU寄存器信息。
我一直在加强，编译和为程序构建代码（用C ++编写，对JVM进行一些JNI调用）几个月，我构建的新版本刚刚发布给客户：因此带有bug报告的tracefile。该跟踪文件由程序生成，只是对应于通过为程序设置自定义异常处理程序（通过SetUnhandledExceptionFilter（））来吐出寄存器数据（包含在_CONTEXT结构中）。
我的客户向我报告说，多年来，以前的开发人员发现这些跟踪文件很有用，并且帮助追踪错误，只有跟踪文件中的信息。
因此我假设它实际上是来自_CONTEXT结构的CPU寄存器输出，以前的开发人员已经发现在跟踪文件中有用，我试图找到一种方法来解释这些信息以帮助追踪什么在发生碰撞时发生了。 （即，正在调用什么函数以及它的参数是什么等等）
在没有任何其他信息的情况下使用CPU寄存器数据也许是不可行的，在这种情况下，我的客户端可能误导我，事实上以前的开发人员拥有包含除CPU注册信息之外的信息的跟踪文件。
所以，这是我想知道的一件事：一般情况下，使用 ONLY 可用_CONTEXT数据结构提供的CPU寄存器信息是否可行将所有源代码都用于成功的Debug＆amp;发布构建环境，获取有用信息吗？
假设答案为“是”，我想知道的第二件事是：如何从_CONTEXT结构中包含的CPU寄存器信息中获取有用信息，假设源代码可用，并且此源代码构建＆amp; Debug和amp;中的开发机器上成功运行发布模式（但不是在最终用户的环境中，没有任何最终用户文件或除了单个跟踪文件之外的数据）？我认为，目标是根据地址定位异常时调用的函数，并希望此函数将是现有代码库中的函数（并且不会嵌套在Windows DLL的内部） 。此外，我的客户表示，之前的开发人员甚至能够获得导致异常的罪魁祸首函数的参数（尽管他再次误导我）。
请注意，最终用户当然正在使用该程序的发布模式构建。我还假设跟踪文件中吐出的_CONTEXT信息将对应于最终用户使用的CPU。
简而言之，我问的是如何解释_CONTEXT结构的各个字段，它们代表Windows上的CPU寄存器，以调试异常的有用方式。寄存器对应的内容是什么我应该看哪些？这是一个页面的链接，其中包含某些（不是所有）CPU的_CONTEXT结构的定义，作为可能的_CONTEXT结构的示例：http://msdn.microsoft.com/en-us/library/ms679284%28VS.85%29.aspx。我不确定最终用户使用的CPU，但如果我确信我可以从_CONTEXT结构中获取一些有用的信息，那么该信息将根据需要轻松提供。请注意，我的跟踪文件显示了128个（4字节）条目 - 这似乎与我见过的_CONTEXT结构的任何的大小不一致（我也查看了WINNT.H，定义_CONTEXT结构的实际文件，乍一看没有看到包含128x4字节的任何可能的定义，但这只是一瞥，我可能会弄错。）
我一直在寻找答案或提示，但还没找到任何有用的。
谢谢，
丹
答案 0 :(得分：1)
我的问题没有正确识别TRACEFILE中存在的信息，也不需要回答。
我道歉。
在查看在问题中提到的跟踪文件中生成数据的代码时，我发现我犯了一个错误。它不是 _CONTEXT 结构，其值正在向tracefile中吐出，而是代码逐步通过 _CONTEXT :: Esp 并吐出（即它正在走路）堆栈本身，在运行时，响应异常 - 它不会吐出CPU寄存器的内容。）
因此，我的问题不再适用。我留在这里只是为了防止问题（或答案）中的信息对其他人有用，尽管这个问题本身并没有得到回答（也不是我需要的）。
谢谢， 丹