windbg反汇编搜索与bp不一致

我使用windbg的

#

命令来搜索WININET dissasembly中出现的文字2f7e。它发现了一个：

0:000> # 2f7e 000007fefde50000+1000
[...snip...]
0:000> # 2f7e
WININET!HTTP_REQUEST_HANDLE_OBJECT::HttpSendRequest_Finish+0x151:
000007fe`fdf0e54d 41be7e2f0000    mov     r14d,2F7Eh

因此，指令的地址是000007fe`fdf0e54d。但是，当我使用符号+偏移量设置断点时，我会得到一个不同的断点地址（请参见断点1）：

所以断点1不是我在

#

中找到的指令：

关于为什么

#

和

bp

将相同的符号名+偏移量解析为不同的地址，有什么想法吗

---

谢谢

旁白：那么您试图解决的WININET问题是什么？@500 InternalServerError我们的一些代码正在使用URLDownloadToFile API，该API在内部调用WININET失败。在调试过程中，我注意到WinINet中的一些调用导致

！gle

报告0x2f7e作为最后一个错误值。所以我想在WinINet中找到任何将该文本作为操作数的指令。我们的想法是，故障发生在该指令附近。仅供参考，WININET加入，它内置了跟踪功能，过去曾帮助我解决过类似问题。@500 InternalServerError很高兴知道，谢谢！原来WinINet正在调用CreateFile，但路径中的一个文件夹被标记为“DELETE PENDING”，因此CreateFile在访问被拒绝的情况下操作失败，但WinINet将该错误代码转换为0x2f7e（0n12158），这是错误\u INTERNET\u无法\u缓存\u文件。URLDownloadToFile将其转换为0x800c0008，这是错误\u INTERNET\u无法\u缓存\u文件。我的procmon过滤器太严格了，否则我会看到原来的访问被拒绝，所以我最终通过一些分解进行了探索。好东西@马克：看来你已经找到答案了。也许你可以把它作为一个答案贴出来，然后马克在两天后就解决了。否则，像我这样的人会试图回答老问题并找到“假阳性”（已经解决但在SO搜索中标记为未解决的问题）。谢谢

0:002> bp WININET!HTTP_REQUEST_HANDLE_OBJECT::HttpSendRequest_Finish+0x151
0:002> bl
 0 e 00000001`3f920124     0001 (0001)  0:**** foo!bar
 1 e 000007fe`fde70ef1     0001 (0001)  0:**** WININET!HTTP_REQUEST_HANDLE_OBJECT::HttpSendRequest_Start+0x744

0:002> u 000007fe`fde70ef1 l1
WININET!HTTP_REQUEST_HANDLE_OBJECT::HttpSendRequest_Start+0x744:
000007fe`fde70ef1 0f846d6a0000    je      WININET!HTTP_REQUEST_HANDLE_OBJECT::HttpSendRequest_Start+0x80e (000007fe`fde77964)