我正在寻找一些高级选项来编码解决我在出站 URL 的 URL 重写模块中发现的一个错误。我们与 Microsoft 陷入僵局，因为他们需要完整的崩溃转储，其中包含机密客户端数据，我们有法律义务与他们共享这些数据。他们无法在我们的服务器上进行调试，因为 URL 重写的符号文件显然受到保护。
我从事基础设施方面的工作，因此对 .Net 的了解并不多。我知道 global.asax 可以进行一些重写，但这是否也适用于出站 URL？
我们可以用代码来实现吗？
还有其他好的选择吗？
对于那些好奇的人来说，有关发现漏洞的详细信息
我们在生产环境中发现了周期性崩溃，而其他环境中从未发生过这种情况。尽管我们的开发环境中有开发流量，测试环境中有用户流量，并且进行了一系列测试，但没有任何测试符合要求。事件日志捕获了带有异常代码的崩溃0xc0000374，这表明堆损坏。
当时，我还不太熟悉调试堆损坏，所以我设置了进程转储作为一个事后调试器，以为崩溃转储会提供更多信息。我们收集的崩溃转储都有不同的堆栈跟踪，而且似乎都是不相关的信息，有时指向我们的应用程序，有时指向 .Net 运行时。
我了解到，调试堆损坏的问题在于检测腐败往往不同于原因损坏。无论哪个线程检测到损坏，检测基本上都不会发生在导致损坏的同一指令上。因此，基本上，您的崩溃转储需要捕获过去的某个时刻。
进入，页面堆。PageHeap 是一个基于每个进程启用的实用程序，它本质上会缓冲所有堆分配，在每个堆对象上方和下方的区域中有一个不可读/不可写的页面。任何超出其内存范围的读取或写入操作都会立即引发异常0xC0000005，这是一种未经授权/非法的内存访问违规，这正是导致堆损坏的原因。
启用 PageHeap 并配置事后调试器后，我们能够捕获一系列崩溃转储。与之前的崩溃转储不同，每个崩溃转储都有完全相同的堆栈跟踪。反编译代码中引发异常的违规指令是一条mul mov指令在 URL 重写模块 DLL 中，它会反复移动内存，操作次数由寄存器中的值决定esx。这符合我们所看到的越界写入行为。
令人惊讶的是，PageHeap 对系统造成的负载并不大。我们的服务器大约有 30GB，而这导致它们负载增加到 38GB。
在发送了小型崩溃转储（仅包含堆栈信息）后，微软确认了这一发现。他们最初认为这是一个已知的 URL 压缩和 URL 重写之间的互操作性问题，但 URL 压缩已被禁用，因此这不适用。
谢谢你的建议，希望你喜欢我的故事:)