“什么都没有的白屏” “Internet Explorer 无法显示该网页”

发布于 2024-11-09 00:55:42 字数 1532 浏览 0 评论 0原文

我们有一个 ASP.NET 网站,有时页面会锁定,没有内容,全白屏,最终在 IE 中超时,返回 IE 错误页面标题“Internet Explorer 无法显示网页”。注意拼写。我们将此称为“无白屏”。

来自 IIS 的日志没有显示任何错误(没有 400 多个状态代码),事实上,显示 IE 进入“无任何白屏”的页面,如 IIS 日志中的状态代码 200。此外,内部服务器端 ASP.NET 跟踪显示所有按预期运行的代码。

尝试重现此错误很困难。它并不总是发生。充其量,如果我们打开页面,关闭它们,并尽可能快地重复此操作,最终会在尝试打开页面和/或刷新框架时发生。同一页面并不总是两次。

某些页面使用 AJAX 控件。大多数使用 GridView。少数使用 Responce.Redirect。没有什么一致的。

搜索“无任何白屏”或“Internet Explorer 无法显示网页”的原因到处都是,而且似乎没有相关性。

我们在 Visual Studio 2008 调试会话中设法捕获了一个“无任何白屏”的实例,其中一个奇怪的未知线程被下面的调用堆栈锁定。请注意,我不确定该调用堆栈是否相关,或者即使它确实被锁定。

[管理到本机的过渡]

System.dll!System.Net.SafeCloseSocket.InnerSafeCloseSocket.Accept(System.Net.SafeCloseSocket socketHandle, byte[] socketAddress, ref int socketAddressSize) + 0x13 字节 System.dll!System.Net.Sockets.Socket.Accept() + 0x73 字节 WebDev.WebHost.dll!Microsoft.VisualStudio.WebHost.Server.OnStart(未使用对象)+ 0x35 字节 mscorlib.dll!System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(对象状态) + 0x2f 字节 mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContextexecutionContext,System.Threading.ContextCallback回调,对象状态)+ 0x6f字节 mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(System.Threading._ThreadPoolWaitCallback tpWaitCallBack) + 0x53 字节 mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(对象状态) + 0x59 字节

该堆栈中的函数均与我们编写的代码无关。我们对“Internet Explorer 无法显示网页”以及该跟踪中调用的函数的各个方面进行了搜索,但似乎没有任何相关性。

有什么想法吗?

We have a ASP.NET website that some times gets pages to lock up, with no content, all white screen, that eventually time out in IE to return an IE error page title "Internet Explorer cannot display the webpage". Note the spelling. We refer to this as the "White Screen of Nothing".

Logs from IIS, show no errors (no 400+ status codes), and in fact, show the page that IE goes into the "White Screen of Nothing" for, as status code 200 in the IIS logs. Also, internal server-side ASP.NET tracing, show all code running as expected.

Trying to reproduce this error is difficult. It does not occur consistently. At best, if we open pages, close them, and repeat this as fast as we can, it will eventually happen on attempt to open a page and/or the refesh of a frame. It is not always the same page twice.

Some pages use AJAX controls. Most use GridViews. A few use Responce.Redirect. Nothing consistant.

Searches for causes of the "White Screen of Nothing" or the "Internet Explorer cannot display the webpage" are all over the place, and do not seem to be related.

We have managed to trap one instance of the "White Screen of Nothing" while in a Visual Studio 2008 debug session, where a weird, unknown thread was locked with the call stack below. Note, I do not know for sure, if this call stack is related or even if it was truly locked.

[Managed to Native Transition]

System.dll!System.Net.SafeCloseSocket.InnerSafeCloseSocket.Accept(System.Net.SafeCloseSocket socketHandle, byte[] socketAddress, ref int socketAddressSize) + 0x13 bytes
System.dll!System.Net.Sockets.Socket.Accept() + 0x73 bytes
WebDev.WebHost.dll!Microsoft.VisualStudio.WebHost.Server.OnStart(object unused) + 0x35 bytes
mscorlib.dll!System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(object state) + 0x2f bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6f bytes
mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(System.Threading._ThreadPoolWaitCallback tpWaitCallBack) + 0x53 bytes
mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(object state) + 0x59 bytes

None of the functions in that stack are related to code we wrote. We did searches on "Internet Explorer cannot display the webpage" and various aspects of the function called in that trace, and nothing seems to be related.

Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

枕梦 2024-11-16 00:55:42

上次我处理这样的问题时,问题是响应时间太长,和/或 IIS 回收了工作进程。由于这类似于资源问题(尝试执行需要过多时间、CPU 或内存的操作),因此修复的细节会有所不同。

PerformWaitCallback 是异步应用程序在等待非常慢的事情时可能停止的地方。

Last time I dealt with an issue like this, the problem was a Response that was taking too long, and/or IIS recycled the worker processes. Since this is like a resource issue (attempting to do something that requires too much time, CPU, or memory), the specifics of the fix will vary.

PerformWaitCallback, is just a likely place for an asynch app to come to a halt if it is waiting on something that is very slow.

粉红×色少女 2024-11-16 00:55:42

我记得有两件事。
验证IIS的回收过程,它可能会在您的进程完成之前回收应用程序池。验证服务器的事件查看器,查看是否有任何 ASP.NET 错误,也许我们可以通过从那里获取的信息为您提供更多帮助。

I can recall of two things.
Verify recycle process of IIS, it may recycling the application pool before your process finish. Verify the Event Viewer of the server, see for any ASP.NET errors maybe we can help you more with information you can get from there.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文