问题标签 [createprocess]

NtCreateProcess和 和有什么不一样ZwCreateProcess？在ntdll.dll中，两者都NtCreateProcess指向ZwCreateProcess完全相同的地址

本质上，我想创建一个新进程并从父进程为其定义环境。我想使用CreateProcessW并将（修改后的）UNICODE 环境传递给lpEnvironment，但我不确定与 ANSII 环境块相比内容应该是什么样子。

我真正找到的唯一文档是在 MSDN 上：

请注意，ANSI 环境块由两个零字节终止：一个用于最后一个字符串，另一个用于终止该块。Unicode 环境块由四个零字节终止：两个用于最后一个字符串，另外两个用于终止块。

现在我试着

1. 调用GetEnvironmentStrings并将其传递给子进程
2. 调用GetEnvironmentStringsW 并将其传递给子进程
3. 使用我的附加环境字符串修改这些块并将其传递

他们都不工作

我真的只能lpEnvironment开始NULL让它工作，但现在我必须改变和恢复我父母的处理环境——这是要走的路吗？

（我也做了设置CREATE_UNICODE_ENVIRONMENT）

谁能告诉我环境块有什么特别之处UNICODE- 它确实有效，当我只是使用ASCII东西并打电话时CreateProcessA()......

CreateProcess文档状态（我的大胆强调）：

lpEnvironment [输入，可选]

[...] 如果 lpEnvironment 指向的环境块包含 Unicode 字符，请确保 dwCreationFlags 包含 CREATE_UNICODE_ENVIRONMENT。如果此参数为 NULL 并且父进程的环境块包含 Unicode 字符，您还必须确保 dwCreationFlags 包含 CREATE_UNICODE_ENVIRONMENT。

MSDN 是错误的并且夸大了标志的含义还是这是一个真正的要求？

我见过从未设置标志并且似乎可以工作的代码，但我偏执的部分希望 100% 遵守 MSDN 所说的。这么说，我不确定你真的可以不走极端就遵循 MSDN 的规则。

当 lpEnvironment 为 NULL 时必须设置（或不设置）CREATE_UNICODE_ENVIRONMENT 让我觉得荒谬：

1. 如果我不传递环境块，则 CreateProcess 必须获取块本身。在那种情况下，它比我知道块的类型更好。

2. 我如何知道该块是否实际包含 Unicode 字符？

   我是否期望得到该块并检查它是否存在当前代码页之外的字符？（我假设这就是 MSDN 在这里所说的“Unicode 字符”的意思。）

   如果我必须获得 env 块，那么我不妨将它传递给 lpEnvionment 而不是 NULL，那么为什么还要允许 NULL？

   对于 CreateProcess 的每个调用者来说，必须获取和检查 env 块似乎是一个疯狂的要求。这肯定是 API 本身应该处理的事情。

3. 当它说“父进程”时，它甚至是指我的进程，即将成为新的父进程，还是意味着我的进程的父进程？我对 MSDN 的初步阅读让我觉得我必须以某种方式判断启动我的进程的 CreateProcess 调用是否已通过 ANSI 或 Unicode 环境块，但事实并非如此。

   我假设，在基于 NT 的操作系统上，所有进程都有一个 Unicode env 块，如果需要在进程创建时从 ANSI 转换，并且进程不会挂在按原样传递给 CreateProcess 的任何数据块上。

   （也许这整个事情是操作系统本身不是 Unicode 的 Win9x 时代的遗留物？即便如此，我也看不出应用程序代码如何比操作系统本身做出更好的决定，也不知道为什么它应该预计会。）

4. 除了从不设置标志的代码外，如果在编译时定义了 UNICODE，我还看到总是设置它的代码。当要求是运行时 env 块中的内容以及代码可能位于加载到外部进程中的 DLL 中时，这是没有意义的。

   env 块是进程范围的，因此在编译时定义的 UNICODE 似乎无关紧要。

5. 如果只是我调用 CreateProcessA 还是 CreateProcessW 的问题，那么当块为 NULL 时该标志应该是隐式的，所以这也没有意义。

在我自己的代码中，我决定避免这个问题并始终获取环境块的 Unicode 副本（通过 GetEnvironmentStringsW），始终将其传递给 CreateProcess 并始终设置 CREATE_UNICODE_ENVIRONMENT。根据 MSDN 的说法，这是我认为 100% 正确的唯一方法。

不过，我所做的当然是多余的。CreateProcess 不可能那么愚蠢，不是吗？

另一方面，这是我们正在谈论的 CreateProcess。它不是设计最好的 API，而且还有很多其他的陷阱（我没想到）：

1. 如果参数字符串是 const 则失败，因为它会就地修改它。
2. 使第一个参数可选，从而使人们忘记在第二个参数中引用 exe 路径。
3. 即使在第一个参数中明确给出，也需要在第二个参数中正确引用 exe 路径。

因此，假设它的行为很聪明或者可能会为呼叫者处理家务也许是不正确的......

我不知道是从我自己的代码中删除偏执的垃圾还是将其添加到我看到的所有其他代码中。啊。:-)

添加于 2010 年 11 月 18 日：

当 env-block 为 NULL 时，至少在 Windows 2000 到 Windows 7 中，该标志似乎无关紧要。请参阅下面的测试。

显然，这并不能断定该标志在所有未来的操作系统中总是无关紧要的，但我真的看不出它会如何。

假设我们有祖父母，它创建了即将创建子的父：

• 如果操作系统总是将 Parent 的 env-block 存储为 Unicode——如果 Grandparent 传递了一个 ANSI 块，在 Parent 的创建过程中将它从 ANSI 转换——那么当 Parent 传递一个 NULL 块时 CreateProcess 将错误地注意标志. CreateProcess 必须知道 Child 将继承的块总是 Unicode。

• 或者，操作系统可以完全按照来自祖父母的方式存储父母的环境块。（这似乎不太可能，但有可能。）在这种情况下，Parent 无法检测 Grandparent 传递的块类型。同样，CreateProcess 必须知道块的类型并忽略该标志。

这是我今天早上写的一个测试，它以不同的方式启动一个子进程，并使子进程报告一个 env-var（为简洁起见，只是“OS”变量）：

这输出：

当 env-block 为 NULL 时，标志在那里无关紧要。

当它不是 NULL 时，标志确实很重要，因为 CreateProcess 需要被告知 void* 背后的内容（但这很明显，问题纯粹是关于 NULL 的情况）。

任何人都可以想到当 env-block 为 NULL 时标志可能很重要的任何场景？在那种情况下，应用程序怎么可能比操作系统本身更了解标志的正确值？

大约两个月以来，我一直在 Windows XP Home SP3 上享受高额的进程创建惩罚。这个问题在创建大量进程的任务中最为明显和烦人，例如 shell 脚本（顺便说一下，Cygwin 上的 bash 脚本）、Makefile 或解压 IzPack 包，例如 SpringSource Tool Suite 安装程序（许多单独的unpack200.exeJAR 提取器进程）。我确定这是通过观察 bash 脚本诊断输出来创建进程，或者观察进程出现在任务管理器中。一旦进程启动并运行，就没有明显的延迟。

我在 Cygwin 邮件列表上报告了这个问题，因为我最初错误地认为只有 Cygwin 受到影响，怀疑 Cygwin DLL 中的错误，或者诸如此类。

Win32（XP Home）更新后速度变慢- （链接到我的帖子到 Cygwin 列表）

我想知道是否某些东西在我认为可能存在于 Windows 上的进程创建钩子中安装了一些垃圾。（与Java 中的安全管理器一样。）病毒还是安全软件？我也没有刻意安装。我还怀疑微软更新故障，但我认为他们现在已经解决了这个问题。

据我所知，Win32 上的进程是由CreateProcess.

我怎样才能找出为什么流程创建需要这么长时间以及这里到底发生了什么？有没有类似straceLinux 的东西，甚至可能有更好的东西？

I'm writing a web testing framework for windows that uses multiple browsers to test web apps. I want to launch the browsers hidden but it's not working.

I'm using CreateProcess to start the browsers with the SW_HIDE flag

It works fine for internet explorer and other apps, but fails with firefox and other browsers. I'm aware that a process is able to choose whether or not to follow the passed flags. Is there any way i can force it to start hidden?

I can probably wait until the window shows up and then hide it by getting a handle to the open window. But I'm looking for cleaner solution.

我使用 CreateProcess() 调用从 C++ dll 启动 Windows CE 3.0 中的应用程序。启动的应用程序按要求运行。但是此应用程序并未作为应用程序列在任务管理器中。只有在任务管理器的设置更改为显示所有进程时才能看到。

如何使启动的进程在任务管理器中显示为应用程序？

（我使用的是windows mobile 6.1，要启动的应用是ac#.net CF应用）

我目前将应用程序转换为使用，CreateProcessW()而不是Runtime.exec()因为我需要它提供的信息。但是，对 CreateProcessW() 的任何调用都会失败，并显示错误代码 5 (ACCESS DENIED)。我一直无法找出为什么会发生这种情况，因为 Runtime.exec() 在相​​同的情况下运行良好。

我的错误可能出现在以下代码片段之一、方法调用和 jna 接口中。

我对 CreateProcessW 的定义

附加信息：

• Runtime.exec() 使用给定的字符串成功
• 设置 StartupInfo 的大小
• 使用的测试环境：WinXP SP3 和 Netbeans 6.9.1

使用的示例参数：

• 名称：moviemk.exe
• 目录：C:\Programme\Movie Maker\

还用不同的路径进行了测试，所以不是空格问题

谢谢

更新：

事实证明，错误是由于我在检查后调用代码在工作目录和 exe 路径周围切换引起的。由于导致访问被拒绝，我实际上认为它至少找到了 exe。我将添加一个 IllegalArgumentException 来解决这个问题。

由于我遇到了与工作目录相关的 exe 附加错误，因此我将接受该答案。感谢大家的帮助。

Win 7/UAC 快把我逼疯了。

在我的 C++ 应用程序中，我需要在 Windows 7 上运行需要提升的可执行文件。我想关闭这个东西并等待它完成后再继续。最简单的方法是什么？

我通常通过 来做这种事情CreateProcess()，但是对于需要提升的可执行文件来说它失败了。

我尝试使用cmd.exe /c ...through运行CreateProcess，它可以工作，但会弹出一个丑陋的 cmd 终端窗口。

我正在阅读这ShellExecute()将允许提升，但在使用ShellExecute(). 像这样简单的事情会system()起作用吗？

非常感谢任何其他想法！

在我的 Win32 应用程序中，我嵌入了 ffplay.exe 用于视频预览。它工作得很好，但每次我开始预览时，光标都会变得“忙碌”，即箭头+沙漏。我想避免这种情况。