问题标签 [createprocesswithlogonw]

We have a service application that launches CMD.exe with Stdin/Stdout/Stderr redirected to a named pipe. The Service is running as an administrator account (It is NOT running as LocalSystem). The development environment is Windows 8.1 Pro.

When we launch CMD.exe using CreateProcessWithLogonW(), it starts and immediate ends with exit code 0xc0000142. If instead, we launch CMD using CreateProcess(), it works fine, which leads me to believe we are tripping over some sort of security model in windows. Note -- the credentials we pass are definitely valid.

This security model theory I believe is further confirmed by the fact that our unittest framework has no problem running CreateProcessWithLogonW() from user space -- but when we move this infrastructure into a windows service it fails. Note -- when we run the unittest, we run using the same administrator account we are using to run the service.

A number of Internet threads discuss exception code 0xC0000142 on google and SO, but they seem to focus on the possibility of a virus outbreak of some sort. We have run the appropriate sfc/scannow to confirm we have a fresh & healthy windows environment. And again I do not believe this is a virus due to the fact that our unittest framework works flawlessly from user space -- it only generates the exception code from within a service:

There are a total a four log entries that are recorded when we encounter the exception code; two for CONHOST.exe and two for CMD.exe. I have reproduced the relevant entries below.

CONHOST.exe entries:

CMD.exe entries

I'd be happy to share code -- but due to the fact this is windows service, even a minimally reproducible example is going to be quite long. I was hoping someone might recognize the issue and point us to some sort of RTFM/security docs from MSDN that might lead us down the right path?

许多程序，如runasWindows 和su*nix 上的程序都采取措施确保用户不会做一些愚蠢的事情，例如在批处理文件中写入密码，方法是确保密码不能通过管道传递给它或作为参数提供。

在工作中，有一项任务需要由另一名员工重复完成，需要以域的管理员帐户登录。我正在编写一个存根应用程序，该应用程序调用CreateProcessWithLogonW以完成此操作，而他们不可能看到纯文本密码，也不必给他们管理员密码。

我担心的是，如果使用十六进制编辑器（甚至是纯文本编辑器）打开密码，密码可能会在可执行文件中显示为纯文本。我是否应该采取措施确保在此应用程序中以混淆方式生成密码？

例如，从这样的结构开始：

然后对位进行运算以生成与登录密码对应的 ASCII。

这对于内部应用程序来说是否过大？

我有一个需要维护的旧 VB6 应用程序。

在应用程序功能中调用了 CreateProcessWithLogonW，它在 Windows 10 上运行时不起作用（但在 Windows 7 上运行良好）。

我通过调用收到的错误代码Err.LastDllError是错误代码 740，我认为它与“请求的操作需要提升”有关。UAC 在我运行它的 Win 10 机器上被禁用，所以我不确定是什么问题来了？？

有人有这方面的经验吗？？任何帮助是极大的赞赏！

真正让我困惑的是它在 Win7 上运行没有任何问题。

代码示例如下：

这是函数声明：

这里是函数调用

下面是 Process 调用的顺序；

1. 服务调用进程 A（这会导致进程 A 在本地系统帐户下运行）。

2. 进程 A 使用 CreateProcessWithLogonW API 在不同的用户帐户（非管理员用户）下启动进程 B（因为不同用户的登录凭据可用）。

3. 进程 B 执行一些涉及调用另一个进程的活动。

直到第 2 步，一切正常。进程 B 在给定的用户帐户下启动，但进程 B 无法执行任务，例如执行批处理文件或使用 CreateProcess API 启动另一个进程。

下面是调用进程B的代码；

下面是进程 B 中用于执行批处理文件的代码；

我有一个运行下一个 vba 代码的 Outlook 2016（64 位），当函数退出时，Outlook 崩溃。该 api 执行良好，我看到记事本在其他用户下启动。

这是功能；

定义如下；

即使在 api 调用后退出该函数，Outlook 也会崩溃并显示下一个报告；

我们有一个 VB6 应用程序，有时需要以提升的权限运行命令，因此我们调用 CreateProcessWithLogonW 函数，这样我们就可以在不需要用户输入凭据的情况下执行此操作。目前，我们使用 xcopy 执行此操作，它可以正常工作。现在我正在尝试实现删除功能，但我在返回代码中得到 0，LastDLLError = 2（我相信这意味着找不到文件）。所以，我认为这种行为的原因是由于 xcopy 是一个外部命令，而 del 是一个内部命令。有没有办法将 del 与 CreateProcessWithLogonW 一起使用？如果没有，是否有任何替代使用“内置”的 del 命令（即不使用批处理脚本、我必须存储在某处的自定义程序等）？

谢谢是提前！