使用Windbg查找由第三方应用程序引起的系统速度下降的原因 [英] Using Windbg to find cause of system slowdown caused by 3rd party application

问题描述

我既是用户又是程序员.背景:编程已有25年，主要使用"BASIC"编程. (当前为VB.Net)，以前曾做过一些C ++汇编程序.我也时不时使用Windbg.

说明
作为用户，我想知道为什么第三方应用程序在不适当的程度上降低了我的系统速度.但是，嘿，我也是一名程序员，所以让我们研究一下.

Hi,

I'm a user as well as a programmer. Background: programming for 25 years, mainly in "BASIC" (currently VB.Net), did some C++, assembler in previous times. I'm also using Windbg now and then.

Description
As a user, I wonder why a 3rd party application is slowing down my system in an inappropriate extent. But, hey, I'm also a programmer, so let's look into it.

系统为Win7/64(Prof)SP1，所有内容均为最新版本，三核 CPU，大量可用的高清空间，8 GB RAM.该应用程序是Mpeg-Muxer(32位进程)，即它读取视频和音频源文件，并将其多路复用为一个单一的电影文件.这主要适用于硬盘驱动器，而不适用于CPU(总CPU使用率的25％ 表示该核心上的75％).源文件和目标文件位于不同的物理驱动器上.在此过程中(可能需要花费几分钟)，计算机的响应速度非常慢.我的意思是真的很慢.例如，在浏览器窗口中滚动是 延迟后，所有应用程序的窗口刷新都非常缓慢，有时甚至鼠标指针也在跳动.即使系统和应用程序安装在其他驱动器上，任何应用程序的应用程序启动时间也几乎是无限的.如果我按 Ctrl + Alt + Del，需要10秒钟直到屏幕变黑，再过10秒钟，直到我看到旋转的光标，再过5秒钟，直到显示期望的窗口.

The system is Win7/64 (Prof) SP1, everything up-to-date, triple-core CPU, plenty of free HD space, 8 GB RAM. The application is an Mpeg-Muxer (32 bit process), i.e. it reads a video and an audio source file and multiplexes it into one single movie file. That's mainly work for the hard drive, less for the CPU (25% total CPU usage means 75% on that core). Source and destination files are on different physical drives. During this process that can take up to a couple of minutes, the machine is responding really slow. I mean really slow. For example, scrolling in the browser window is delayed, windows of all applications are refreshing very slowly, and sometimes even the mouse pointer is jumping. Application startup time of any application is almost endless even though the system and applications are installed on other drives. If I press Ctrl+Alt+Del, it takes 10s til the screen turns black, another 10 seconds til I see the spinning cursor, another 5s til the expected window is shown.

请相信我的经验，这是不正常的，无法用两个繁忙的硬盘驱动器和一个75％的CPU核心来解释.可能还有其他原因导致此延迟.为该语句添加权限:没有其他制造HD和/或 CPU工作会导致这种现象.例如，如果我使用另一种方式进行操作的不同应用程序("ProjectX")，即将电影文件解复用为单独的视频和音频文件，则不会出现这种系统速度降低的情况.这不仅是 一次经验.自从去年从WinXP切换到Win7以来，这种情况一直在发生.在WinXP上效果很好.

Just trust my experience that this not normal and can not be explained by two busy hard drives and one 75% busy CPU core. There must be something else causing this delay. To add authority to this statement: No other application that makes the HDs and/or CPU work causes such a behavior. For example, if I use a different application ("ProjectX") that does it the other way round, i.e. it demuxes a movie file into separate video and audio files, there is no such system slow down noticable. This is not only a one-time experience. It's happening always since switching from WinXP to Win7 last year. It worked well on WinXP.

根据进程浏览器"，该进程在内核模式下花费5％，在用户模式下花费20％.

According to "Process Explorer", the process is spending 5% in kernel mode and 20% in user mode.

问题
我能够将Windbg附加到正在运行的Mpeg-muxer进程中.我可以不时打断一下，看看调用堆栈.我的问题是，这没有揭示导致上述症状的原因.长话短说: 如何找到它?
该进程运行三个线程.他们中的两个一直在等待.整个工作都在UI线程中完成！这也意味着，如果我单击窗口图标，该图标显示窗口菜单(还原，移动，最小化等)被中断，并且继续 窗口菜单关闭后.

Question
I'm able to attach Windbg to the running Mpeg-muxer process. I can interrupt from time to time and look at the callstack. My problem is that this doesn't reveal what causes the mentioned symptoms. Long story short: How can I find it out?
The process runs three threads. Two of them are waiting all the time. The whole work is done in the UI thread! This also means, if I click on the window icon, which shows the window menu (restore, move, minimize, etc) processing is interrupted, and it's continued as soon as the window menu is closed.

旁注
我注意到的另一件事可能与之无关:如果我打开Windows的资源监视器"，并查看硬盘活动"窗格中，整个文件的读取/写入是通过系统"完成的. (PID 4)进程，而不是由多路复用器进程本身.此外， 在退出多路复用器进程之后，系统进程将继续写入目标文件几秒钟(可能是10s)，这意味着数百兆字节.这不会是系统缓存问题，因为用户看不到它.

Side note
Another thing I've noticed and that might be related or not: If I open Windows' "ressource monitor" and look at the "hard disk activity" pane, the whole file reading/writing is done by the "System" (PID 4) process, not by the muxer process itself. In addition, after the muxer process has already been quitted, the System process continues writing the destination file for several seconds (maybe 10s), which means hundreds of megabytes. This can not be a system cache issue because it wouldn't be visible to the user.

 

那么，从哪里可以开始调试此问题?我知道这个论坛不是关于内核调试的，而且我也不打算这样做.但是，也许有一种方法可以使用Windbg在用户模式下缩小问题范围.如前所述，大部分时间都花在了 用户模式.

So, where could I start debugging this issue? I know this forum is not about kernel debugging, and I don't intend to do it. However, maybe there is an approach how to narrow the problem down in user mode using Windbg. As said before, most time is spent in user mode.

感谢阅读！

推荐答案

调用堆栈的一个快照:(在Process Explorer中制作.Windbg不会显示太多细节)

One snapshot of the call stack: (made in Process Explorer. Windbg doesn't reveal as many details)

这篇关于使用Windbg查找由第三方应用程序引起的系统速度下降的原因的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！