爲什麼WmiPrvSE.exe持有我的進程'作業對象的句柄？

我有一個.NET應用程序，它產生多個孩子'工作進程'。我正在使用Windows作業對象API和JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE設置來確保子進程總是在父進程終止時被終止。爲什麼WmiPrvSE.exe持有我的進程'作業對象的句柄？

但是，我已經觀察到父母關閉後仍在機器上運行的多個孤兒進程。使用Process Explorer，我可以看到它們仍然正確地分配給作業，並且作業具有配置的正確的「關閉作業關閉」設置。

JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE的文檔狀態爲：「導致與作業關聯的所有進程在作業的最後一個句柄關閉時終止。」

這似乎意味着作業的句柄仍然處於打開狀態...我搜索了Job對象的句柄，並在結果中找到了WmiPrvSE.exe的實例。如果我終止了相關的WmiPrvSE.exe進程，Job的未完成句柄顯然已關閉，並且所有孤立的應用程序進程都按預期終止。

WmiPrvSE.exe如何處理我的工作？

來源

2016-01-25 Chris Brook

你可能會發現this blog在整理WmiPrvSE正在做的事情。

WmiPrvSE是WMI Provider主機。這意味着它託管WMI提供程序，這是DLL。所以幾乎可以肯定的是，WmiPrvSE並沒有處理你的工作，但它所託管的提供商之一是這樣做的。爲了找出哪個供應商是罪魁禍首，一種方法是遵循here的流程，然後查看哪個獨立流程持有該句柄。

確定哪個提供者持有句柄後，您可以嘗試根據提供者管理的系統組件推導出哪種查詢會對您的作業有句柄。或者，如果您不關心失去對提供商提供的組件的管理權限，則可以禁用該提供商。

如果您可以確定哪種查詢將持有句柄，則可以推斷出發出查詢的程序。或者，也許eventlog可以告訴你（上面的第一個鏈接）。

爲了得到更多的幫助，請提供在OP，比如哪些供應商在WMIPRVSE，任何相關的事件日誌事件運行的其他詳細信息，以及其他任何診斷信息，你獲得。

編輯16年1月27日

的方法來找出發生了什麼導致WMIPRVSE獲得你的工作的手柄是使用WinDbg的！HTRACE擴展。在加載.EXE但在Windbg中執行之前，您需要運行!htrace -enable。然後，您可以稍後打開並執行!htrace <handle>以查看操縱手柄時的堆棧軌跡。你可能想從這開始article on handle implementation.

來源

2016-01-26 05:22:06

感謝您的幫助 - 這絕對是WmiPrvSE流程，它擁有對作業的處理（而不是另一個查詢WMI的流程）。我已經啓用診斷日誌按上面的博客，但我也沒辦法告訴* *的時候把手就開了，這是很難的根本原因關聯到衆多的WMI事件之一。不過謝謝 - 我會繼續堅持下去。 –

另一個查詢WMI的進程可能會導致WMIPrvSE打開一個句柄。WMIPrvSE，據我的理解，WMIPrvSE不會自動行動，但由於WMI查詢。因此，即使另一個進程正在執行查詢並且沒有直接擁有該句柄，那另一個進程可能是罪魁禍首。另請參閱我對此答案的編輯。 –

爲什麼WmiPrvSE.exe持有我的進程'作業對象的句柄？

回答

相關問題