1

This is a weird one for sure.

If I open a command prompt window directly (searching cmd in start, right click > open command window here, cmd within bat file, etc....) all commands entered run perfectly fine.

If I open a command prompt window from within my C++ application (system("cmd"); or QProcess::startDetached("cmd"); etc....) the commands I enter throw errors.

Here are a few commands that don't work in the cmd opened from my app:

vssadmin delete shadows /all
vssadmin list shadows
wmic
shadowcopy

and so on... I get Class not registered and Initialization failure errors all around. Anything to do with shadow copies isn't working at all. But again, the weird thing is, those same commands work perfectly fine when cmd was opened traditionally (not from a program). Both instances of cmd have admin privileges.

So my question is, how come the way I open cmd affects whether or not some commands work? Everything I can see says there should be no difference.

phuclv
  • 37,963
  • 15
  • 156
  • 475
mrg95
  • 2,371
  • 11
  • 46
  • 89
  • Your launching cmd from a vanilla windows exe? – Alex K. Sep 08 '15 at 10:14
  • When opened like every other human being, all commands work fine. When opened within my uber basic generic Qt C++ project, those listed commands (and more to do with shadow copies) don't work. So yes. vanilla as it gets. This has been tested with multiple programs on multiple computers. Try it yourself, I bet it will do the same thing. – mrg95 Sep 08 '15 at 10:16
  • 1
    Is the output of the `set` command the same for both? – Alex K. Sep 08 '15 at 10:16
  • No they're different. The one from within my program has about 3 times more stuff. – mrg95 Sep 08 '15 at 10:18
  • Also, entering the command directly like `system("vssadmin delete shadows /all");` just skips right to the error. – mrg95 Sep 08 '15 at 10:36
  • 2
    Run c:\windows\syswow64\cmd.exe and you'll probably get the exact same errors. Time to start building programs to target x64. – Hans Passant Sep 08 '15 at 10:36
  • Yep. Calling `system("c:\\windows\\syswow64\\cmd.exe");` and entering the commands returns the errors. Same for when I open it directly. Calling `system("c:\\windows\\system32\\cmd.exe");` also returns the errors. But works fine when opened directly. – mrg95 Sep 08 '15 at 10:40
  • Other than compiling as 64 bit, know of any quick hotfixes to send the commands to the 64 bit version of cmd? – mrg95 Sep 08 '15 at 11:19

1 Answers1

3

32-bit applications running on WOW64 will be put under file system redirection. Therefore if your app is a 32-bit one, the call system("c:\\windows\\system32\\cmd.exe"); will be redirected to C:\Windows\SysWOW64\cmd.exe and 32-bit cmd will always be invoked. You have some solutions:

  • Use system("c:\\windows\\sysnative\\cmd.exe"); to access the real system32 folder and get the 64-bit cmd
  • Turn off file system redirection explicitly (should be avoided in general)
  • Or better compiling it as a 64-bit app.
phuclv
  • 37,963
  • 15
  • 156
  • 475
  • Thanks! Not only did this work, but I've learned a lot of new stuff in the process. :) – mrg95 Sep 08 '15 at 11:25
  • 1
    You should avoid the second option ("turn off file system redirection") as it isn't thread-safe. – Harry Johnston Sep 08 '15 at 23:41
  • @HarryJohnston yes I just listed it as a "possible" way here but it's not recommended as MS said ["A 64-bit executable file located under %windir%\System32 cannot be launched from a 32-bit process, because the file system redirector redirects the path to %windir%\SysWOW64. Do not disable redirection to accomplish this; use %windir%\Sysnative instead."](https://msdn.microsoft.com/en-us/library/windows/desktop/aa384203%28v=vs.85%29.aspx) – phuclv Sep 09 '15 at 04:55