是否已弃用CreateProcessW？ [英] Is CreateProcessW deprecated?

问题描述

我找不到一个确切的答案，所以我决定问。

I couldn't find a precise answer so I've decided to ask.

我一直在阅读内部Windows调试，并在示例中告诉我在 kernel32！Cre​​ateProcessW 上设置一个断点。

I've been reading the "Inside Windows Debugging" and in the sample it tells me to set a breakpoint on the kernel32!CreateProcessW.

但是之前它使用了 .symfix 调试器命令将调试器符号搜索路径设置为指向Microsoft在线符号服务器。当我尝试设置断点时，我会收到一个无法解析该函数​​的错误（或类似的东西）。看起来像这样。

But before that it uses the .symfix debugger command to set the debugger symbols search path to point to the Microsoft online symbols server. When I try to set the breakpoint I get an error that it cannot resolve the function (or something like that). It looks like this.

0:000> bp kernel32!CreateProcessW
Couldn't resolve error at 'kernel32!CreateProcessW'

可能因为在下面的列表中没有kernel32！Cre​​ateProcessW。

It's probably because there's no "kernel32!CreateProcessW" in the list below.

0:000> x kernel32!CreateProcess*
76b90cb9 KERNEL32!CreateProcessWithTokenW (void)
76b90d84 KERNEL32!CreateProcessAsUserW (void)
76b90d84 KERNEL32!CreateProcessWithLogonW (void)
76b4e225 KERNEL32!CreateProcessWStub = <no type information>
76b72e04 KERNEL32!CreateProcessInternalAStub = <no type information>
76b72e15 KERNEL32!CreateProcessInternalWStub = <no type information>
76b72de2 KERNEL32!CreateProcessAStub = <no type information>
76b72df3 KERNEL32!CreateProcessAsUserWStub = <no type information>

如果我将断点设置为 kernel32！Cre​​ateProcessWStub 想知道为什么我找不到并将断点设置为 kernel32！Cre​​ateProcessW 。

Everything goes fine if I set the breakpoint to kernel32!CreateProcessWStub but I wondered why I couldn't find and set the breakpoint to the kernel32!CreateProcessW.

这本书可能关注一个使用Windows 7的读者我正在使用Windows 8.1，并且可能认为kernel32！Cre​​ateProcessW已被弃用...

This book probably focuses on a reader who's using Windows 7. I'm using Windows 8.1 and thought maybe that kernel32!CreateProcessW got deprecated...

我对这个领域非常新鲜，道歉如果这是一个完全愚蠢的题。但是感谢您阅读它。

I'm extremely new to this field and apologize if this is a completely stupid question. But thanks for reading it anyway.

推荐答案

CreateProcessW is definetely not deprecated 。此外，唯一记录的记录的入口点仍然在kernel32.dll中，因此对于所有意图和目的，您应该继续通过kernel32.dll调用CreateProcessW，而不是通过kernelbase.dll。

CreateProcessW is definetely NOT deprecated. Furthermore, the only documented documented entry point is still in kernel32.dll, so for all intents and purposes you should continue calling CreateProcessW through kernel32.dll, and not through kernelbase.dll.

以下是一些更多的细节，以帮助您了解您观察的内容。 Windows团队经常移动代码，而对于最近的几个版本，他们有较强的习惯，将较大的DLL分解成较小的DLL，其中包括kernel32，ole32，user32，gdi32等等。这不是新的，2006年，Raymond Chen 写了这个 Raymond描述的机制是基于转发器，而您在这里看到的内容是使用 kernel32！Cre​​ateProcessW 是一个存根，即调用kernelbase！CreateProcessW然后返回的函数：

Here is some more details to help understand what you are observing. Windows team often moves code around, and for the last few releases they had strong habit of breaking larger DLL's into smaller ones, which includes kernel32, ole32, user32, gdi32 to name a few. It is not new, Raymond Chen wrote about this in 2006. However the mechanism Raymond describes is based on forwarders, while what you see here with kernel32!CreateProcessW is a stub, i.e. the function that calls kernelbase!CreateProcessW and then returns:

0:014> u kernel32!CreateProcessWStub l14
KERNEL32!CreateProcessWStub:
00007ffd`83cf58a8 4c8bdc          mov     r11,rsp
00007ffd`83cf58ab 4883ec58        sub     rsp,58h
00007ffd`83cf58af 488b8424a8000000 mov     rax,qword ptr [rsp+0A8h]
00007ffd`83cf58b7 498943f0        mov     qword ptr [r11-10h],rax
... skip ...
00007ffd`83cf58f5 ff1555871100    call    qword ptr [KERNEL32!_imp_CreateProcessW (00007ffd`83e0e050)]
00007ffd`83cf58fb 4883c458        add     rsp,58h
00007ffd`83cf58ff c3              ret 

函数调用为ca n看到是kernelbase！CreateProcessW

The function called as you can see is kernelbase!CreateProcessW

0:014> ln poi kernel32!_imp_CreateProcessW
(00007ffd`82f92604)   KERNELBASE!CreateProcessW   |  (00007ffd`82f926d0)   KERNELBASE!MakeLocHashNode
Exact matches:
    KERNELBASE!CreateProcessW (no parameter info)

我这个例子我不知道为什么Windows人们决定使用存根而不是转发器，对我来说，简单地转发一个电话似乎更有效率大部分的其他重构已经完成。

I this case I don't know why Windows folks decided to use a stub rather than a forwarder, to me it seems it would be more efficient to simply forward a call, like most of the other refactoring was done.

Windows 8.1中的Kernel32.dll仍然包含导出符号CreateProcessW。命令 link / dump / exports 打印出所有导出符号：

Kernel32.dll in Windows 8.1 still contains export symbol CreateProcessW. Command link /dump /exports prints out all export symbols:

c:\>link /dump /exports c:\Windows\System32\kernel32.dll | findstr CreateProcessW
        220   DB 000058A8 CreateProcessW = CreateProcessWStub

您可以使用相同的命令来确定你应该设置断点。对于转发的导出类似：

You can use the same command to determine where you should set breakpoint to. Similarly for forwarded exports:

c:\>link /dump /exports c:\Windows\System32\kernel32.dll | findstr EnterCriticalSection
        298  129          EnterCriticalSection (forwarded to NTDLL.RtlEnterCriticalSection)
       1418  589          TryEnterCriticalSection (forwarded to NTDLL.RtlTryEnterCriticalSection)

WinDbg无法解析符号kernel32！Cre​​ateProcess的原因可能只是WinDbg中的一个错误。在这种情况下，符号不是.PDB文件的一部分，但包含在PE映像的特殊部分中，显然WinDbg不处理。有趣的是，如果.PDB文件不可用，WinDbg很乐意使用PE映像的导出表：

The reason why WinDbg cannot resolve symbol kernel32!CreateProcess, is probably just a bug in WinDbg. In this case, the symbols is not part of .PDB file, but contained in a special section in PE image, and apparently WinDbg does not handle that. What is interesting is that if .PDB file is not available, WinDbg is happy to use export table of PE image:

0:014> .sympath .
0:014> .reload
Reloading current modules ....
0:014> x kernel32!CreateProcessW
00007ffd`83cf58a8 <b>KERNEL32!CreateProcessW</b> (no parameter info)

显然，WinDbg决定使用PDB符号或导出符号，但不能同时使用两者。

Apparently WinDbg decides to use either PDB symbols or export symbols, but not both.

这篇关于是否已弃用CreateProcessW？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！