VS反汇编窗口是否显示整个EXE？
一位客户正在运行我公司的程序，但它在到达任何地方之前就停止了。 他们从 Windows 事件日志中发送了以下信息：
faulting module program.exe, version 1.2.3.4, fault address 0x00054321.
我们没有太多其他事情可做，因此作为最后的努力，我一直在尝试查看是否可以在反汇编程序中找到该位置。 我通过 Visual Studio 运行该程序，暂停它，查看反汇编窗口并尝试滚动到该地址，但我得到的只是：
00054321 ???
00054322 ???
00054323 ???
00054324 ???
00054325 ???
00054326 ???
00054327 ???
00054328 ???
00054329 ???
0005432A ???
这是否是因为 Visual Studio 只反汇编了靠近暂停位置的 EXE 部分或其他内容？ 我很难查看实际拆解了多少内容，因为滚动条无法完全发挥作用。 （我无法抓住并移动滚动位置；我必须按行或按页滚动。）
感谢您的任何见解！
A client is running my company's program and it is halting before it gets anywhere. They sent this information from the Windows Event Log:
faulting module program.exe, version 1.2.3.4, fault address 0x00054321.
We don't have much else to go on so as a last ditch effort I've been trying to see if I can find where that position is in a disassembler. I run the program through Visual Studio, pause it, look at the Disassembly window and try scrolling to that address but all I get there is this:
00054321 ???
00054322 ???
00054323 ???
00054324 ???
00054325 ???
00054326 ???
00054327 ???
00054328 ???
00054329 ???
0005432A ???
Would this be because Visual Studio only disassembles part of the EXE near the pause position or something? It's hard for me to look through how much is actually disassembled because the scrollbar doesn't work fully. (I can't grab and move the scroll position; I have to scroll by line or by page.)
Thanks for any insight you may have!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
错误地址也可能是由堆栈损坏问题引起的，即。 返回地址可能会被泄露并跳回到错误的地址@ 0x54321。
此外，根据所使用的技术（Java、.NET），代码可能会在运行之间更改其位置。
Visual studio对整个流程空间进行了拆解。 ???? 意味着该位置不可访问。
您最好需要一个堆栈框架来从核心转储中查看发生了什么。
The fault address could also be caused from a stack corruption problem, ie. the return address could be compromised and jumped back to the wrong address @ 0x54321.
Also, depending on the tecnology used (Java, .NET) the code could change it's position between runs.
Visual studio makes a disassembly of the whole process space. ???? means that the position is not accessible.
You'd better need a stack-frame to see what's happening, from a core dump.
WinDbg 可能是您的朋友，您可以在那里加载可执行文件和符号（.pdb），如果您可以获得 QbProg 所说的（迷你）转储，这肯定会简化搜索。 但我有过在 WinDbg 中更容易做到这一点的经验。
WinDbg may be your friend here, there you can load your executable and the symbols (.pdb), if you can get a (mini)dump as QbProg says that would definitely ease the search. But I have had experiences when it was easier doing this in WinDbg.
您希望在反汇编窗口中看到什么？ 这种方法是行不通的。 如果您能够重建与客户端运行的完全相同的构建配置，则可以启用 /MAP 项目链接选项中的选项。 这将创建一个将符号映射到地址的文件，并允许您查看崩溃发生时正在执行哪个函数。 您可能需要进行一些计算，以将原始映射地址与客户端 PC 上加载模块的地址进行偏移。
正如 Fredrik 所说，WinDbg 或许也能提供帮助，特别是如果您可以从客户端的 PC 获取故障转储。
What are you expecting to see in the disassembly window? This approach is not going to work. If you are able to rebuild the exact same build configuration of that your client is running then you can enable the /MAP option in the project's link options. This will create a file that maps symbols to addresses and will allow you to see which function was executing when the crash occurred. You may have to do a bit of calculation to offset the raw mapped address against the address the module was loaded at on the client's PC.
As Fredrik says, WinDbg may be able to help too, especially if you can get a crash dump from your client's PC.