Cmd exe ошибка при запуске приложения 0xc0000142

• На главную
• Категории
• Операционные системы
• Windows
• Ошибка 0xc0000142

Многие пользователи при запуске exe-приложений сталкиваются с ошибкой 0xc0000142, из-за которой системные и сторонние программы могут неправильно работать или вовсе не запускаться.

2020-10-16 02:07:43219

Answers

• The problem seems to be fixed with Cumulative Update KB4025342 from July 11 2017!

  • Marked as answer by
    asking_man
    Wednesday, July 12, 2017 10:34 AM

All replies

• Did you mean that exact command the whole line?

  

  If I put;

  cmd.exe /c start /b more.com <nul

  That give three blank lines (approx.) but does not error. Does this happen on multiple machines for you?

• The better command line is (the double quotes are important):

  start cmd.exe /c «start /b more.com <nul»

  you can also use:

  start cmd.exe /c «start /b mode.com con»

  This happens on all (two) machines I updated to 1703. On 1607 (and Windows 7) machines this works.

  more.com is only a placeholder for any program, but since it is provided by Microsoft, I used this.

  This currently breaks my Siemens SCADA system from working.

  • Edited by
    asking_man
    Wednesday, May 10, 2017 9:04 PM

• Ok thanks. The start cmd.exe /c «start /b mode.com con» does give the error once in a while. Look for a work-around I would say.

• Thanks so far.

  When I attach windbg to the failed process, I get the following information:

  0:000> k
  Child-SP          RetAddr           Call Site
  000000c1`7667f328 00007ff9`424301c0 ntdll!NtRaiseHardError+0x14
  000000c1`7667f330 00007ff9`4244a4c7 ntdll!LdrpInitializationFailure+0xab968
  000000c1`7667f370 00007ff9`423f9b2b ntdll!_LdrpInitialize+0x50987
  000000c1`7667f3f0 00007ff9`423f9ade ntdll!LdrpInitialize+0x3b
  000000c1`7667f420 00000000`00000000 ntdll!LdrInitializeThunk+0xe
  0:000> lm
  start             end                 module name
  00007ff6`da820000 00007ff6`da82c000   more       (deferred)            

  00007ff9`42380000 00007ff9`4255b000   ntdll      (private pdb symbols)  d:arsymbolsntdll.pdb41D57AE3B178CDF490C0B78265127E9B1ntdll.pdb

  Unloaded modules:
  00007ff9`3fab0000 00007ff9`3fb5e000   KERNEL32.DLL
  00007ff9`3f4f0000 00007ff9`3f739000   KERNELBASE.dll

• • Edited by
    Karen_HuMicrosoft contingent staff
    Thursday, May 11, 2017 6:10 AM

• Hi,

  I’ve checked the syntax, and it seems ok for me.

  The stuff with the command line is already a deep analysis of how my SCADA system is starting its child processes and reduces the things to the main problem.

  Here is a snipped from a little C++ program I’ve written to reproduce the error:

  STARTUPINFOW si;
  PROCESS_INFORMATION pi;
  memset(&si, 0, sizeof si);
  si.cb = sizeof si;
  wchar_t* pszCmd = L"cmd.exe /c start /b mode.com con";
  BOOL isSuccess = CreateProcessW((wchar_t*)0, pszCmd, NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, &si, &pi);
  

  This works on Windows 7 and Windows 10 1607 but on Windows 10 1703 I get error 0xC0000142. Our Siemens SCADA Software is currently not working on Windows 10 1703 because it cannot start its child processes.

• The 0xC0000142 maps to STATUS_DLL_INIT_FAILED, and the cmd error code 9059.

  More interestingly,

  C:UsersAdmin>start "" "%comspec% /c start /b more.com <nul"

  results in

  [Window Title]
  C:WINDOWSsystem32cmd.exe /c start /b more.com <nul

  [Content]
  Windows cannot find ‘C:WINDOWSsystem32cmd.exe /c start /b more.com <nul’. Make sure you typed the name correctly, and then try again.

  [OK]
  But only because of the missing closing parenthesis.

  Incorrect

  C:UsersAdmin>start "" "%comspec% /c start /b more.com <nul"

  Your example misses the second parenthesis.

  Correct

  C:UsersAdmin>start "" "%comspec%" /c start /b more.com <nul"

  C:UsersAdmin>start "" "C:windowssystem32cmd.exe" /c start /b more.com <nul"

  either works fine, or throws 0xC0000142 for ‘more’/’mode’.

  —————————
  mode.com — Application Error
  —————————
  The application was unable to start correctly (0xc0000142). Click OK to close the application. 
  —————————
  OK   
  —————————

  Temporary solution, it seems, would be to specify the direct path to the cmd interpreter and to use quotes for cmd. Moreover, once you specify the full path, all subsequent commands in the same cmd session can be run directly by using %comspec%
  or cmd.exe without having to provide the full path.

  ---

  Well this is the world we live in And these are the hands we’re given…

  • Edited by
    Exotic Hadron
    Thursday, May 11, 2017 9:54 AM

• You have an additional quote in the second command line at column 38, if you add this quote to your first given command line the behavior is the same.
  The first command line I have given at the thread start [start «» «cmd.exe /c start /b more.com <nul»] was incorrect. It must be [start «» «cmd /c start /b more.com <nul»]. Please use the better command line from
  my first reply [start cmd.exe /c «start /b more.com <nul»]. The problem is not to get the command line running — it is the third party software, that uses such child process creating methods.

• You have an additional quote in the second command line at column 38, if you add this quote to your first given command line the behavior is the same.
  The first command line I have given at the thread start [start «» «cmd.exe /c start /b more.com <nul»] was incorrect. It must be [start «» «cmd /c start /b more.com <nul»]. Please use the better command line from
  my first reply [start cmd.exe /c «start /b more.com <nul»]. The problem is not to get the command line running — it is the third party software, that uses such child process creating methods.

  Why are you using this syntax while invoking external application:

  start "" "command <params>"

  instead of using

  start "" "command" <params>"

  Also, the terminating quote does not seem to play any role since you are terminating with the NUL device. Both commands work fine to me:

  C:UsersAdmin>start "" "cmd" /c start notepad <nul"
  
  C:UsersAdmin>start "" "cmd" /c start notepad <nul

  ---

  Well this is the world we live in And these are the hands we’re given…

• The command lines are only for reproduction of the problem that exists in our third party software in compiled binary form. Up to now this software works fine but fails on Windows 10 Version 1703.

• Initially, you’ve stated that

  «more.com is only a placeholder for any program, but since it is provided by Microsoft, I used this.»

  so I thought you are expecting issues specifically with ‘start’ and not with CreateProcess().

  ---

  Well this is the world we live in And these are the hands we’re given…

• The command lines are only for reproduction of the problem that exists in our third party software in compiled binary form. Up to now this software works fine but fails on Windows 10 Version 1703.

  Could
  this be your case?

  ---

  Well this is the world we live in And these are the hands we’re given…

• Sorry, no. The problem is that it was working on Windows 7 and Windows 10 Version 1607 and on Windows 10 Version 1703 it’s not working.

• Hi,

  Based on the test result, it’s indeed like what you said.

  

  Please submit this feedback via the built-in Feedback App. And I will also submit it via our own channel.

  Hope it would be fixed soon.

  ---

  Please remember to mark the replies as answers if they help.
  If you have feedback for TechNet Subscriber Support, contact
  tnmff@microsoft.com.

• Hi, Thanks for your answer.

  I’ve submitted the problem using «Feedback Hub».

• What are the odds you got any feedback to you feedback??

  We’ve got an app that spawns a console app and had utilized the AllocConsole() API prior to the CreateProcess() call in the parent process.
  Exactly the same thing is happening to us on the machines that updated to creators.
  I can also utilize you start /b methodology to get the same effect..

  This had worked for years, think it had something to do with io redirecting for logging at the time..

  Simply removing that AllocConsole() / FreeConsole() pair got our stuff going again..
  Though I need to work through the repercussions of that..

  If you’ve got anymore insight that’d be great.

• I’ve got no comment on my feedback on «Feedback Hub» yet,

  and I have not the possibility to modify my third party (Siemens) software to get it running again — like you — and sorry I haven’t any more details for you. It had worked all the times up to creators update. I think I’ve to wait til Microsoft fixes it or
  Siemens has a workaround for it. By the way «start /b» is used by the software to create detached processes.

  Here’s the story I’ve posted on «Feedback Hub»:

  Title: Child processes created with the command «cmd /c start /b» and the flags CREATE_NO_WINDOW or CREATE_NEW_CONSOLE failed to start with error 0xC0000142

  Description: My third party SCADA software creates its detached child processes with the command line «cmd /c start /b app.exe». This ends up in an API call to CreateProcess(0, «cmd /c start /b app.exe», 0, 0, FALSE, CREATE_NO_WINDOW,
  0, 0, &si, &pi). This can be easily reproduced with the command «start cmd.exe /c start /b mode.com con» in a command window. Since the update to Windows 10 version 1703 (10.0.15063) every newly created process is terminated with error 0xC0000142
  so my SCADA software isn’t running anymore.

  • Edited by
    asking_man
    Wednesday, June 21, 2017 5:36 PM

• The problem seems to be fixed with Cumulative Update KB4025342 from July 11 2017!

  • Marked as answer by
    asking_man
    Wednesday, July 12, 2017 10:34 AM