记一次 .NET 某人力资源网 CPU爆高分析
<h2 id="一背景">一：背景</h2><h3 id="1-讲故事">1. 讲故事</h3>
<p>前段时间微信里有一位非训练营学员找到我，说他们的系统在某些时段会cpu爆高，并伴有网络带宽的激增，不知道是什么情况，让我帮忙看下怎么回事，哈哈，说这个故障之前，我先吐槽一下，地狱不空，在社区里我一个人的力量太微弱了，这5年来我给行业内开发朋友都是全免费分析，这也让自己不堪重负，不得不考虑收缩，目前非学员首单免费，也只有我的训练营学员才会永久免费分析。给自己的学员分析dump还是比较轻松的，毕竟大家都是有一定的调试体系知识，同根同源。</p>
<p>吐槽完毕，开始本篇的dump分析之旅。</p>
<h2 id="二cpu爆高分析">二：CPU爆高分析</h2>
<h3 id="1-为什么会cpu爆高">1. 为什么会cpu爆高</h3>
<p>关于cpu爆高的dump，最好用procdump自动去抓，因为在我的分析之旅中，有不少人手工去抓cpu爆高往往都不大准，还有一点一定要相信数据而不是人言，使用 <code>!tp</code> 观察cpu的利用率。</p>
<pre><code class="language-C#">
0:000> !tp
CPU utilization: 100%
Worker Thread: Total: 20 Running: 5 Idle: 7 MaxLimit: 32767 MinLimit: 12
Work Request in Queue: 0
--------------------------------------
Number of Timers: 2
--------------------------------------
Completion Port Thread:Total: 1 Free: 1 MaxFree: 24 CurrentLimit: 1 MaxLimit: 1000 MinLimit: 12
</code></pre>
<p>从卦中看确实cpu被打爆，恰好昨天分析了一个 .net2.0 的dump，可气的是没有 <code>!tp</code> 命令，这就非常考验我们的clr知识了，需要知道 <code>CPU utilization</code> 这个值 sos 是从哪里取得的？如果你看过sscli源代码，应该知道它是 <code>win32threadpool.cpp</code> 的一个全局变量。</p>
<pre><code class="language-C++">
SVAL_IMPL(long,ThreadpoolMgr,cpuUtilization);
</code></pre>
<p>接下来用 windbg 验证下。</p>
<pre><code class="language-C#">
0:000> xclr!ThreadpoolMgr::cpuUtilization
00007ffb`08541558 clr!ThreadpoolMgr::cpuUtilization = <no type information>
0:000> dp clr!ThreadpoolMgr::cpuUtilization L1
00007ffb`0854155800000000`00000064
0:000> ? 0x64
Evaluate expression: 100 = 00000000`00000064
</code></pre>
<p>从卦中看完全对上了，所以dump分析多了，不能对 sos 有太多的依赖。</p>
<p>接下来我们看下cpu的能力，因为自我分析过2core cpu程序之后，我对cpu的健壮性一直都非常好奇，有时候cpu爆高不是业务问题，是 cpu 真的太弱了，接下来使用 <code>!cpuid</code> 观察便知。</p>
<pre><code class="language-C#">
0:000> !cpuid
CPF/M/SManufacturer MHz
06,85,7<unavailable> 2500
16,85,7<unavailable> 2500
26,85,7<unavailable> 2500
36,85,7<unavailable> 2500
46,85,7<unavailable> 2500
56,85,7<unavailable> 2500
66,85,7<unavailable> 2500
76,85,7<unavailable> 2500
86,85,7<unavailable> 2500
96,85,7<unavailable> 2500
106,85,7<unavailable> 2500
116,85,7<unavailable> 2500
</code></pre>
<p>从卦中看当前是一个 8core 的cpu，能力方面还算说的过去，接下来使用 <code>~*e !clrstack</code> 观察下每个线程都在做什么？</p>
<pre><code class="language-C#">
0:000> ~*e !clrstack
OS Thread Id: 0x77fc (0)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
Failed to start stack walk: 80070057
...
OS Thread Id: 0x74c4 (58)
Child SP IP Call Site
0000002f9c85e4c8 00007ffb14ea058a System.Threading.Thread.JoinInternal(Int32)
0000002f9c85e5d0 00007ffb06def9fe System.Threading.Thread.Join(System.TimeSpan)
0000002f9c85e610 00007ffaaaa62f42 FreeRedis.Internal.IdleBus`2[,].ThreadJoin(System.TimeSpan)
0000002f9c85e6d0 00007ffaaaa62422 FreeRedis.Internal.IdleBus`2[,].ThreadScanWatchHandler()
...
OS Thread Id: 0x6618 (63)
Child SP IP Call Site
0000002f9bffcff8 00007ffb14ea001a System.Net.UnsafeNclNativeMethods+OSSOCK.recv(IntPtr, Byte*, Int32, System.Net.Sockets.SocketFlags)
0000002f9bffcff8 00007ffb057310b2 System.Net.UnsafeNclNativeMethods+OSSOCK.recv(IntPtr, Byte*, Int32, System.Net.Sockets.SocketFlags)
0000002f9bffcfd0 00007ffb057310b2 DomainNeutralILStubClass.IL_STUB_PInvoke(IntPtr, Byte*, Int32, System.Net.Sockets.SocketFlags)
0000002f9bffd080 00007ffb056ae48f System.Net.Sockets.Socket.Receive(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags, System.Net.Sockets.SocketError ByRef)
0000002f9bffd100 00007ffb056ac845 System.Net.Sockets.NetworkStream.Read(Byte[], Int32, Int32)
0000002f9bffd170 00007ffb056ac6b1 System.Net.PooledStream.Read(Byte[], Int32, Int32)
0000002f9bffd1d0 00007ffb056ad4a1 System.Net.Connection.SyncRead(System.Net.HttpWebRequest, Boolean, Boolean)
0000002f9bffd230 00007ffb056d07bb System.Net.ConnectStream.ProcessWriteCallDone(System.Net.ConnectionReturnResult)
0000002f9bffd270 00007ffb056c4ea9 System.Net.HttpWebRequest.CheckDeferredCallDone(System.Net.ConnectStream)
...
</code></pre>
<p>从卦象中看，只有几个线程有调用栈，并且大多都挂在 <code>event</code> 事件上，这些并不能导致 cpu 爆高，这就让人很迷茫了，难道这个也是手工抓取的不准吗？</p>
<h3 id="2-走出迷雾">2. 走出迷雾</h3>
<p>在思考了若干秒之后，马上就意识到既然托管层没问题，或许非托管有问题呢？毕竟 <code>~*e !clrstack</code> 是一个肌肉记忆命令，接下来使用 <code>~* k</code> 观察各个非托管栈，果然发现有多处 <code>ipFilter</code> 外来模块，截图如下：</p>
<p><img src="https://img2024.cnblogs.com/blog/214741/202508/214741-20250825102448557-1962349278.png"></p>
<p>从卦中看 <code>ipFilter</code> 貌似是一个 ip过滤器，正在忙碌的处理，看样子正在高频计算导致的cpu临时性爆高，那 ipFilter 是何方神圣呢？使用 <code>lmvm ipFilter</code> 观察一下便知。</p>
<pre><code class="language-C#">
0:079> lmvm ipFilter
Browse full module list
start end module name
00007ffb`041c0000 00007ffb`041f0000 ipFilter (export symbols) ipFilter.dll
Loaded symbol image file: ipFilter.dll
Image path: D:\软件\安全软件\YunSuoAgent\x64\ipFilter.dll
Image name: ipFilter.dll
Browse all global symbolsfunctionsdata
Timestamp: Wed Feb5 19:14:48 2020 (5E3AA3A8)
CheckSum: 000367C5
ImageSize: 00030000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
</code></pre>
<p>接下来拿 YunSuoAgent 到 bing上搜一下，原来是 <code>云锁</code> 这款安全软件，截图如下：</p>
<p><img src="https://img2024.cnblogs.com/blog/214741/202508/214741-20250825102448565-924238536.png"></p>
<h3 id="3-云锁为什么会拦截">3. 云锁为什么会拦截</h3>
<p>云锁为什么会拦截，这个真搞不清楚，只能简单猜测下，拿其中的 <code>79号线程</code> 具体来说，使用 <code>k</code> 和 <code>!dso</code> 命令。</p>
<pre><code class="language-C#">
0:079> k
# Child-SP RetAddr Call Site
00 0000002f`915ed080 00007ffb`041c89a7 ipFilter+0x12bd
01 0000002f`915ed0b0 00007ffb`041c81ab ipFilter+0x89a7
02 0000002f`915ed130 00007ffb`041c87e9 ipFilter+0x81ab
03 0000002f`915ed350 00007ffb`041c3298 ipFilter+0x87e9
04 0000002f`915ed440 00007ffb`041c9050 ipFilter+0x3298
05 0000002f`915ed5b0 00007ffb`041c920d ipFilter+0x9050
06 0000002f`915ed670 00007ffb`043201de ipFilter+0x920d
07 0000002f`915ed6c0 00007ffb`04320219 FilterKernel+0x501de
08 0000002f`915ed730 00007ffb`04320219 FilterKernel+0x50219
09 0000002f`915ed7a0 00007ffb`04330c92 FilterKernel+0x50219
0a 0000002f`915ed810 00007ffb`044f4524 FilterKernel+0x60c92
0b 0000002f`915ed850 00007ffb`045a297f agent_iis7_module!RegisterModule+0x1594
...
0:079> !dso
OS Thread Id: 0x74e4 (79)
RSP/REG Object Name
0000002F915ED9B8 0000002e062ccb60 System.Web.HttpContext
0000002F915ED9C0 0000002e062cc800 System.Web.Hosting.IIS7WorkerRequest
0000002F915EDEE8 0000002e062d0558 System.String /WebResource.axd
0000002F915EDF00 0000002d058ed588 ASP.global_asax
0000002F915EDF08 0000002d058ed588 ASP.global_asax
0000002F915EDF20 0000002e062d0558 System.String /WebResource.axd
0000002F915EDF40 0000002e062d0558 System.String /WebResource.axd
...
</code></pre>
<p>从卦中可以看到 ipFilter.dll 是注册到 iis 的一个 httpmodule，同时也看到了一个比较特殊的 <code>/WebResource.axd</code> 文件，熟悉 asp.net 的朋友应该知道，它其实是一个 httphandler，专用来动态产生 css，js 资源的，不需要将 css，js 放到物理文件中，在网上也有很多关于 <code>/WebResource.axd</code> 的漏洞注入案例，所以这东西是 ipfilter 的重点监控之处，不过直接导致 cpu 爆高，这就有点让人无语了。</p>
<p>将结果告诉朋友之后，让朋友将 <code>云锁</code> 关掉，CPU 终于下去了。</p>
<h2 id="三总结">三：总结</h2>
<p>今年遇到了好几起 <code>安全软件</code> 导致的各种问题，内存泄露，程序卡死，程序崩溃，以及本篇的 CPU 爆高，也是无语了。。。</p>
<img src="https://images.cnblogs.com/cnblogs_com/huangxincheng/345039/o_210929020104最新消息优惠促销公众号关注二维码.jpg"><br><br>
来源：https://www.cnblogs.com/huangxincheng/p/19056425
頁:
[1]