Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2243
  • Last Modified:

CreateProcessWithLogonW from service causing 0xc0000142

I have a service running under a local admin account (not system). I'm in the process of adding functionality to execute programs (typically non-interactive tools) under different user accounts. This can happily be limited to W2K and up, so I figured CreateProcessWithLogonW was the way to go.

Now to the problem: the first time the service launches an app via CreateProcessWithLogonW, it works perfectly. Any subsequent launches result in a system dlg for error 0xc0000142 (application failed to initialize properly). This on XP + SP2.

When this happens, the service itself does not detect any error and keeps running quite happily. The dlg title always relates to the tool being launched, and a quick check of taskmgr shows the tool in the process list until I dismiss the dlg that is.

One more thing - I've written my service so that it can also run as a normal console app for easier testing. When I run it like this, the launches work perfectly every time. The exact same code is executing, under the same admin account, but this time it isn't running from a service environment.

Here's how I'm calling CreateProcessWithLogonW. szUser, szPwd and szDir are valid unicode strings. cmd is actually a CByteArray (MFC) containing a unicode version of the command line. My typical test command is cmd.exe /C "c:\test.bat" (where test.bat just does something like dir > c:\out.txt). si and pi are zeroed out, then I set si.cb prior to the call.

bResult = CreateProcessWithLogonW( szUser,
                              NULL,
                              szPwd,
                              LOGON_WITH_PROFILE,
                              NULL,
                              (LPWSTR) cmd.GetData(),
                              0,
                              NULL,
                              szDir,
                              (LPSTARTUPINFOW) &si,
                              &pi );

Any ideas?
0
infofinder
Asked:
infofinder
  • 5
  • 3
  • 2
  • +1
1 Solution
 
jkrCommented:
Actually, the error code is

# for hex 0xc0000142 / decimal -1073741502 :
  STATUS_DLL_INIT_FAILED                                        ntstatus.h
# {DLL Initialization Failed}
# Initialization of the dynamic link library %hs failed. The
# process is terminating abnormally.

I am taking a wild guess here that this is one of the system DLLs (which is th emost common reason) and would point you to http://support.microsoft.com/?id=184802 ("PRB: User32.dll or Kernel32.dll fails to initialize")
0
 
itsmeandnobodyelseCommented:
>>>> the first time the service launches an app via CreateProcessWithLogonW,
>>>> it works perfectly.
It may work perfectly cause the dlls needed were in the default path (or maybe in the same path than the service) and it may fail later as you changed the working directory in the meantime or for some other path reasons.

You might add the dll paths to the 'path' environment variable defined for system and not for the user logged on. Be also aware that LocalSystem account has no access to network devices.
0
 
infofinderAuthor Commented:
Thanks jkr and itsmeandnobodyelse.

I took a look at jkr's MS link and tried the reg hack to increase the heap available to non-interactive window stations. I made sure I restarted between each test, but it didn't seem to make any difference, so I think that rules out "cause 2" from the article.

However, I have made a further discovery: if change the command to:

cmd.exe /C "c:\windows\notepad.exe"

then this command can launch successfully many times without error. Swap it back to cmd.exe /C "c:\test.bat" (where test.bat contains only dir > c:\out.txt) and again I get one good launch, followed by the error noted in my first post. Both these commands use an instance of cmd.exe, but for some reason the batch file causes trouble, whilst launching notepad always succeeds.

I don't know if this points to one of the other suggestions made by either of you. Certainly I've checked through the code and I'm not changing the working directory or modifying the path variable.

I'm going to keep testing and researching in the hope that inspiration strikes, in the meantime I'd really appreciate it you guys or anyone else could chip in with more ideas. This thing is doing my head in!
0
Microsoft Certification Exam 74-409

VeeamĀ® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

 
jkrCommented:
Do you really need to log on with the full user profile being loaded? Does the same happen when you use LOGON_NETCREDENTIALS_ONLY instead?
0
 
infofinderAuthor Commented:
jkr: "Do you really need to log on with the full user profile being loaded? Does the same happen when you use LOGON_NETCREDENTIALS_ONLY instead?"

Well the idea is that a user can specify the command line they want the service to execute, so I guess sometimes it'll be needed, sometimes it won't. But I'd better be able to get it working for cases where it is required.

Also, a bit more information - maybe this will provide more clues. The 0xc0000142 happens after any of the launched processes has closed. If they all stay running, then I the service can continue to launch more. But once any one of those processes has exited, the next launch results in 0xc0000142. That accounts for the difference in the behavior of the two commands I've observed, but I don't know what the underlying cause could be?
0
 
itsmeandnobodyelseCommented:
If launching a batch job you should set the CREATE_NEW_CONSOLE flag. The default is to inherit the console window from the parent but that may fail for a service. In case of launching notepad via cmd the console window actually wasn't needed as notepad is a win32 application. That is different when ivoking abatch that needs the console window as a shell.
0
 
infofinderAuthor Commented:
itsmeandnobodyelse: "If launching a batch job you should set the CREATE_NEW_CONSOLE flag"

Yup I tried setting that initially but it didn't make any difference. After a closer look at the MSDN doc for CreateProcessWithLogonW I realized that CREATE_NEW_CONSOLE, along with CREATE_DEFAULT_ERROR_MODE, and CREATE_NEW_PROCESS_GROUP are set by default. You can supply additional flags but those are always "ON".

Fresh testing seems to indicate that it's the fact that first command (with the batch) terminates that makes the difference. I can get the same behavior with the notepad launch if I terminate a previously launched instance of notepad.

--/--

jkr:"Does the same happen when you use LOGON_NETCREDENTIALS_ONLY instead?"
When I tried this, I got: A logon request contained an invalid logon type value. (0x00000557)
Just setting 0 for the logon flags exhibited the same behavior as LOGON_WITH_PROFILE.

0
 
itsmeandnobodyelseCommented:
>>>> I can get the same behavior with the notepad launch
>>>> if I terminate a previously launched instance of notepad.

So it is more that a second 'CreateProcessWithLogonW' doesn't get the needed resources if a previous 'session' was terminated by user request.

Did you free the handle you got by CreateProcessWithLogonW?


0
 
infofinderAuthor Commented:
>>>> So it is more that a second 'CreateProcessWithLogonW' doesn't get the needed resources if a
>>>>previous 'session' was terminated by user request.

Yep, but not just termination by user request. If the app self-terminates cleanly I still end up in with the oxc0000142 error.

>>>> Did you free the handle you got by CreateProcessWithLogonW?

I'm calling CloseHandle on the hProcess and hThread fields of the PROCESS_INFORMATION structure immediately after the call. As far as I'm aware that's the only cleanup required?
0
 
DanRollinsCommented:
I'm no expert in this, but the dox indicates some sort of shenanigans with the registry hive -- there are warnings...

>> CreateProcessWithLogonW does not load the specified user's profile into the HKEY_USERS registry key. This means that access to information in the HKEY_CURRENT_USER registry key may not produce results consistent with a normal interactive logon...

There is also something to do with serialized access to certain key functions (found in an older version of MSDN).  It occurs to me that on exit from an app, the system might revert the "hack" and thus make the system unstable.  At the bottom of

    CreateProcessWithLogonW Function
    http://msdn2.microsoft.com/en-us/library/ms682431.aspx

The community Content shows something more of a hint in that direction.  If  CreateProcessWithLogonW ends up with an app that causes an automatic logoff and session closure when it exits,  then we might expect some problems.  Such oddball behavior might be a reason why this function is not allowed for the LocalSystem account.

If I hit a roadblock like this, I'd try recoding with LogonUser and CreateProcessAsUser

-- Dan
0
 
infofinderAuthor Commented:
Thanks everyone for their replies. I think Dan may have found a lead on why I'm getting this annoying behavior with CreateProcessWithLogonW, but in the end his advice about taking a different approach was the winner for me.

I didn't go with LogonUser / CreateProcessAsUser though - instead I went for Task Scheduler. The COM interface is easy to use, and Task Scheduler even takes care of running a process truly interactively if the target user happens to be logged on at the time. All in all, way less effort than the direct method.
0
 
DanRollinsCommented:
Thanks for the points and the A grade.

Using the Task Scheduler is a great idea.  It should avoid a lot of annoying potential problems.   I'll remember it :-)

-- Dan
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now