.net wpf 应用程序启动问题
我的应用程序有一个非常奇怪的启动行为。
第一次启动应用程序时，该进程会占用一个 CPU 核心（双核为 50%，四核为 25%），并且 RAM 消耗停止在特定值（每个启动相同，在其他计算机上不同/不同构建版本为我们改变应用程序来测试）。
如果我在第一个实例运行时启动另一个实例，第二个实例将正常启动。
我在应用程序中插入了一些日志记录，似乎应用程序在第一次显示 UI 元素时崩溃了。最初的日志记录在启动屏幕应该显示之前结束 - 删除启动屏幕后，它停止为应该显示消息框控件。
该问题发生在某些机器上，而不是全部机器上。将相同的文件复制到另一台计算机可以“修复”该问题。如果我部署由我的工作站构建的调试编译版本，问题就会完全消失。
附加信息（3 月 18 日）：所需的“挂起”实例计数似乎取决于可用内核的数量。
如果计算机在双核*系统上运行，则第二个进程启动，第一个进程占用 50% CPU (= 1 core@100%)。如果机器在四核系统上运行，则*第四个进程*启动，前三个进程各占用25%的CPU（= 3核@100%）。
更新（3 月 19 日）： 所以......我们解决了它！ 一位同事编写了一个线程管理器，其中包含一些代码来等待某些事情。当显示 UI 元素时调用此管理器。在非常慢的虚拟机上运行调试版本或运行发布版本（运行良好的机器是一台非常繁忙的机器上的虚拟机器）似乎会改变时间并使其正常工作。
他说他实施了某种超时来解决这个问题。
我将在周一仔细研究他的解决方案（以及为什么需要如此奇怪的事情），并在此处发布更新，以便为以下访问者提供针对我的问题的正确解决方案。
赏金归Stephen Chung所有，感谢大家的帮助。
I've got a quite strange startup behavior for my application.
The first time the application is started the process takes up one CPU Core (50% on dual core, 25% on quad core) and RAM consumption stops at a specific value (each start the same, different on other machines/different build versions as we change the application around to test).
If I start an other instance while the first is running the second instance starts normally.
I inserted some logging into the application and it seems the application crashes the first time a UI element is shown. Initially logging ended just before the splash screen should show up - after removing the splash screen it stopped as a Messagebox Control should be shown.
The issue happens on some machines, not all. Copying the same files to an other machine can "fix" the problem. If I deploy a debug compiled build, builded by my workstation the issue disappears completely.
Additional Info (March 18th): The required "hanging" instances count seems to depend on the number of available cores.
If the machine runs on a dual core* system, the second process starts, the first taking 50% CPU (= 1 core@100%). If the machine runs on a quad core system the *fourth proces*s starts, the first three taking 25% CPU each (= 3 cores@100%).
Update (March 19th):
So... we solved it!
A colleague wrote a thread manager with some code to wait on something. This manager is called when UI elements are shown. Running a debug version or running the release version on a very slow VM (the machine which functioned fine has been a virtual one on a really busy machine) seem to change the timing and make it work.
He said he implemented some sort of timeout to fix it.
I will take a closer look at his solution (and why such strange things are required) on Monday and post an update here to provide a proper solution to my question for following visitors.
The bounty goes to Stephen Chung, thank you all for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你的问题不是很清楚。您应该尝试提供尽可能多的调试/错误日志信息。
预感如下
但是，考虑到您正在使用 100% 的 CPU 核心，这听起来很可疑。你在占用线程吗？你使用线程池吗？ .NET 程序至少需要一些空闲的 ThreadPool 线程才能运行 - 几年前，如果您占用 ThreadPool 中的线程（运行永无休止的循环等），并且空闲的数量线程数低于3，系统就会崩溃。如果您正在使用线程池，则应该检查线程池中的空闲线程数。
这只是一种预感。
总结问题
但是，我试图在下面总结您的问题。看看我是否理解正确：
失败模式
这种模式似乎表明，当您的最后一个程序在最后上占用了 100% 的时间时， > CPU、Windows 进程都在争夺 CPU 时间。
如果您有一个空闲核心，那么 Windows 进程始终可以在该核心上运行，并且您的 UI 将做出响应。一旦您也将其占用，您可能会看到 Windows 在无响应的应用程序上检测到超时 - 您可能对计算机造成了很大的压力，以至于 Windows 无法运行。
测试：运行n 个程序实例（n = 核心数）。然后运行其他程序。他们会表现迟缓，还是表现良好？
Your question is not very clear. You should try to provide as much debug/error log info as possible.
Hunch below
However, considering that you are using 100% of a CPU core, this sounds suspicious. Are you hogging threads? Are you using ThreadPool? .NET programs require at least a few spare ThreadPool threads to operate -- a couple of years ago, it used to be that if you hog up the threads in the ThreadPool (running never-ending loops etc.), and the number of free threads drop below 3, the system will crash. You should check the number of free threads in the ThreadPool if that's what you're using.
This is only a hunch.
Summarizing the problem
However, I am trying to summarize your problem below. See if I get it right:
Failure pattern
This pattern seems to suggest that, when your last program hogs up 100% time on the last CPU, Windows processes are left fighting for CPU time.
If you have one core free, then Windows processes can always run on that core and your UI will be responsive. Once you hog that up too, you may be seeing a time-out detected by Windows on unresponsive applications -- you may be straining the machine so much that Windows cannot function.
To Test: Run n program instances (n = number of cores). Then run other programs. Will they be sluggish, or will they run fine?
是的，您应该针对所有相同版本的运行时，您还应该查看 融合日志（.NET 加载程序尝试获取正确版本的二进制文件的日志）。
查看 Suzanne 的博客，她提供了大量有关冷启动性能问题/调整的信息。
Yeah, you should target all the same version's of runtime, also you should look at the fusion log (logs of .NET loader trying to get the correct version of your binaries).
Check out Suzanne's blog she has lots of info about cold startup performance issues/tweaking.
尝试剥离应用程序启动代码。如果问题在启动屏幕出现之前就出现了，那么要么是您的代码导致机器停止运行，要么是 WPF 中出现了问题。
您是否在应用程序对象构造函数中运行任何代码？
Try stripping down the application startup code. If the problem shows even before the splash screen is visible either you have code that is stalling the machine or there is something wrong in WPF.
Are you running any code in the Application object constructor?