在CMD.exe中，“start sh.exe”创建一个需要700 MB内存的conhost进程

Git bash（sh.exe）否则占用很少的内存，但是当用CMD启动时 start sh.exe 命令，它创建一个需要3-700 MB内存的conhost.exe进程。

有趣的是 start cmd /k sh.exe 做同样的事情，但它创建了只需要8 MB的conhost进程。

为什么用“start”命令启动sh.exe会创建一个需要更多内存的conhost进程？

— laggingreflex
source

你是如何测量它所占用的内存量的？那你的“记忆”是什么意思？你的意思是物理内存（RAM）？

— David Schwartz

@DavidSchwartz 任务管理器显示~300MB，Process Explorer显示~700MB（专用字节）

— laggingreflex

那么，那不是物理记忆。然后简短的回答是，没有人关心这个价值是什么。只有物理记忆是稀缺的，通常人们不会费心去减少非稀缺资源的消耗。

— David Schwartz

@DavidSchwartz我测量了资源监视器中的总RAM使用率，峰值和下降似乎相似。此外，当有10个这样的conhosts时，我的chrome会在一段时间后访问时暂停一段时间。我已经看到了一个改进，避免以我的问题中描述的方式启动conhosts（使用 start cmd sh.exe 代替 start sh.exe ）。我的问题是 为什么 有什么区别？为什么conhost在做的时候会占用更多的内存（甚至只是虚拟） start sh.exe 做比较 start cmd /c sh.exe

— laggingreflex

答案就是我所说的 - 虚拟内存并不稀缺，所以人们不会费心去减少它的消耗。分配相当大的块是很常见的，以防以后需要它。在启动流程时尤其如此，因为在启动之前您可以执行一些操作，这些操作无法轻松完成。

— David Schwartz

好的，我看着两个跟踪WPA.exe 。在显示高内存使用情况的跟踪中，内存使用来自创建屏幕缓冲区 DoCreateScreenBuffer：

Line #, Process, Commit Stack, Address, Count, Impacting Size, Size
1, conhost.exe (10848), [Root], , 46, 800784384, 800833536
2, ,    |- ntdll.dll!RtlUserThreadStart, , 31, 800669696, 800673792
3, ,    |    kernel32.dll!BaseThreadInitThunk, , 31, 800669696, 800673792
4, ,    |    |- ConhostV2.dll!ConsoleIoThread, , 13, 800509952, 800509952
5, ,    |    |    ConhostV2.dll!ConsoleHandleConnectionRequest, , 13, 800509952, 800509952
6, ,    |    |    ConhostV2.dll!ConsoleAllocateConsole, , 13, 800509952, 800509952
7, ,    |    |    |- ConhostV2.dll!SetUpConsole, , 10, 800460800, 800460800
8, ,    |    |    |    |- ConhostV2.dll!AllocateConsole, , 7, 800432128, 800432128
9, ,    |    |    |    |    ConhostV2.dll!DoCreateScreenBuffer, , 7, 800432128, 800432128
10, ,   |    |    |    |    |- ConhostV2.dll!SCREEN_INFORMATION::CreateInstance, , 6, 800415744, 800415744
11, ,   |    |    |    |    |    ConhostV2.dll!TEXT_BUFFER_INFO::CreateInstance, , 6, 800415744, 800415744
12, ,   |    |    |    |    |    |- ConhostV2.dll!DBCS_SCREEN_BUFFER::CreateInstance, , 4, 599891968, 599891968
13, ,   |    |    |    |    |    |    ntdll.dll!RtlpAllocateHeapInternal, , 4, 599891968, 599891968
14, ,   |    |    |    |    |    |    ntdll.dll!RtlpAllocateHeap, , 4, 599891968, 599891968
15, ,   |    |    |    |    |    |    ntdll.dll!NtAllocateVirtualMemory, , 4, 599891968, 599891968
16, ,   |    |    |    |    |    |    ntoskrnl.exe!KiSystemServiceCopyEnd, , 4, 599891968, 599891968
17, ,   |    |    |    |    |    |    ntoskrnl.exe!NtAllocateVirtualMemory, , 4, 599891968, 599891968
18, ,   |    |    |    |    |    |    ntoskrnl.exe! ?? ::NNGAKEGL::`string', , 4, 599891968, 599891968

该 start cmd /k sh.exe 一，不做这种内存分配。这里只打印了一些字符，仅使用69kB。

Line #, Process, Commit Stack, Address, Count, Impacting Size, Size
7, conhost.exe (10072), [Root], , 2, 81920, 81920
8, ,   ntdll.dll!RtlUserThreadStart, , 2, 81920, 81920
9, ,   kernel32.dll!BaseThreadInitThunk, , 2, 81920, 81920
10, ,   |- ConhostV2.dll!ConsoleIoThread, , 1, 69632, 69632
11, ,   |    ConhostV2.dll!SrvWriteConsole, , 1, 69632, 69632
12, ,   |    ConhostV2.dll!DoSrvWriteConsole, , 1, 69632, 69632
13, ,   |    ConhostV2.dll!DoWriteConsole, , 1, 69632, 69632
14, ,   |    ConhostV2.dll!WriteChars, , 1, 69632, 69632
15, ,   |    ConhostV2.dll!WriteCharsLegacy, , 1, 69632, 69632
16, ,   |    ConhostV2.dll!WriteRegionToScreen, , 1, 69632, 69632
17, ,   |    ConhostV2.dll!ConsolePolyTextOut, , 1, 69632, 69632
18, ,   |    ntdll.dll!RtlpAllocateHeapInternal, , 1, 69632, 69632
19, ,   |    ntdll.dll!RtlpAllocateHeap, , 1, 69632, 69632
20, ,   |    ntdll.dll!RtlpCommitBlock, , 1, 69632, 69632
21, ,   |    ntdll.dll!NtAllocateVirtualMemory, , 1, 69632, 69632
22, ,   |    ntoskrnl.exe!KiSystemServiceCopyEnd, , 1, 69632, 69632
23, ,   |    ntoskrnl.exe!NtAllocateVirtualMemory, , 1, 69632, 69632
24, ,   |    ntoskrnl.exe! ?? ::NNGAKEGL::`string', , 1, 69632, 69632
25, ,   |  , 0x2a657431000, 1, 69632, 69632

但我不知道为什么会这样。始终使用start cmd / k运行它。

— magicandre1981
source

啊！我的屏幕缓冲区大小设置为9999 不知道为什么它只适用于 start sh.exe 但是将它降低到合理的值会产生conhost，而不是那么多的内存使用量。该死的！大声笑。谢谢你的分析！

— laggingreflex

当我第一次看到这条痕迹时，我也想过这个，但忘记添加它。但很高兴听到它现在已修复:)

— magicandre1981