Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The operation completed successfully on stderr #249

Closed
dcjulian29 opened this issue Apr 17, 2015 · 16 comments
Closed

The operation completed successfully on stderr #249

dcjulian29 opened this issue Apr 17, 2015 · 16 comments

Comments

@dcjulian29
Copy link

I have a package that "works" in 0.9.8 and has started to be "unsuccessful" when installed on computers running the new choco 0.9.9. I've run the package on both Windows 8.1 and 10 and get the same:

[ERROR] -  The operation completed successfully.

and the package fails to install. This specific package changes some registry settings and I've verified that they are indeed changed. I've also updated the install script to output the $LastExitCode after each line in the script and don't see any non-zero exit codes...

Console Output: https://gist.github.com/dcjulian29/e38de448ce54af997137

Chocolatey Log: https://gist.github.com/dcjulian29/7b9deb1be194f4fe7ef6

@ferventcoder
Copy link
Member

Running this by hand, what is the exit code?

reg.exe import C:\ProgramData\chocolatey\lib\mysettings-ntfs\tools\registry.reg /reg:64

Keep in mind that $lastexitcode may does not apply to posh commands - http://joshua.poehls.me/2012/powershell-script-module-boilerplate/ You need $?

@ferventcoder
Copy link
Member

Out of curiousity, did it work in 0.9.8.33? That one was a bit better at detecting errors than its predecessors.

@dcjulian29
Copy link
Author

Running from a command shell

 C:\ProgramData\chocolatey\lib\mysettings-ntfs\tools>reg.exe import registry.reg /reg:64
 The operation completed successfully.
 C:\ProgramData\chocolatey\lib\mysettings-ntfs\tools>echo %errorlevel%
 0

Running from a powershell:

 PS C:\Windows\system32> reg.exe import registry.reg /reg:64
 The operation completed successfully.
 PS C:\Windows\system32> $?
 True

Yes, it does work without issue on my systems that are still running 0.9.8.33...

@ferventcoder
Copy link
Member

Any chance I can get the package in question (or one that has the same issues) for local testing?

@dcjulian29
Copy link
Author

@ferventcoder ferventcoder added this to the 0.9.9.6 milestone Apr 20, 2015
@ferventcoder ferventcoder modified the milestones: 0.9.9.6, 0.9.9.7 May 16, 2015
@ferventcoder
Copy link
Member

This is a tough one. Adding $ErrorActionPreference = "Stop" hasn't helped. Wrapping the whole thing in a try catch doesn't trap the error (even with the stop preference). I wonder if it is coming back from one of the commands. I'm going to systematically remove everything and step through each until I find the culprit. Hopefully that will help find the issue.

@ferventcoder
Copy link
Member

Okay, so

reg.exe import C:\ProgramData\chocolatey\lib\mysettings-ntfs\tools\registry.reg /reg:64

Exits with this status:

The operation completed successfully.

And an exit code of 0. Why that is getting fed to the error stream in what remains to be seen.

@ferventcoder
Copy link
Member

At this reference note this:

      If InStr(1,oExec.StdErr.ReadAll,"operation completed successfully",vbTextCompare) Then
             ' Yes the success text IS sent out via StdErr and NOT StdOut
             WScript.Echo "Registry updated sucessfully"
             oFSO.DeleteFile sTempFile
      Else
             WScript.Echo "regWriteBinary: Registry import of " & sTempFile & " failed: " & oExec.StdErr.ReadAll
      End If

I've found the problem. The main problem is in reg.exe utility.
Depending on the version reg.exe utility works differently. v5.1.x.x (that I have on my XPSP3) works correctly, but v5.2.x.x does not work as it is expected to work.

"reg import" command:

  • when v5.1: returns "Operation completed successfully" to standard OUTPUT stream
  • when v5.2: returns "Operation completed successfully" to standard ERROR stream

Moreover, it is probably a problem with PowerShell also :(
PowerShell treats these streams differently and process ERROR stream messages as errors. Which is correct imho. But for some reason the PowerShell console and PowerShell v2 ISE behavior is different in this case. (ISE shows the error just like the PowerGUI ScriptEditor does).

@ferventcoder
Copy link
Member

This actually looks like an issue with reg.exe and not with new/old Chocolatey. Or rather the POSH version of choco was maybe forgiving on this.

I did flip over to 0.9.8.33 and it has no issues installing and it appears to return the message back as what looks like no error at all. I'm not quite sure what the correct path forward is.

@dcjulian29
Copy link
Author

I believe the whole reason I switched to using the reg.exe tool was because sometimes PowerShell gets confused on the "bitness" of the registry if the PowerShell host is running the 32-bit shell on a 64-bit operating system when using the the PowerShell Registry Provider to change the registry...

I think I can work around this by calling out to the underlying .Net API to deal with the registry after determining if the system is 64-bit...

$key = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, [Microsoft.Win32.RegistryView]::Registry64)

$subKey =  $key.OpenSubKey("SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management", $true)

$subKey.SetValue("DisablePagingExecutive", 1)

I believe the path forward is to not fault Choco for "doing the right thing" and to possibly submit a bug against the underlying tool being called from the script... Based on your research and discoveries, it doesn't appear to be a bug in chocolatey.

@ferventcoder
Copy link
Member

Unfortunately this is not just local to reg.exe. Perhaps the right thing to do is workaround it. :/

@ferventcoder ferventcoder changed the title Package Install is Successful in 0.9.8.x but Unsuccessful in 0.9.9.x The operation completed successfully on stderr Jun 13, 2015
ferventcoder added a commit that referenced this issue Jun 13, 2015
It seems that many applications out there can return this error and
still exit with a zero exit code, when this is logged within the
PowerShell service runner, it should redirect that back to the info
stream and not count it as a fail point. If PowerShell does exit with a
non-zero status, then we should count the whole install as a failure no
matter what messages were logged. In this way the exit code 0 and the
message "The operation completed successfully" are not considered a
failure.

References:
https://rcmtech.wordpress.com/2012/03/06/vbscript-and-reg_binary-registry-values/
http://en.community.dell.com/techcenter/powergui/f/4833/t/19570669

>I've found the problem. The main problem is in reg.exe utility.
>Depending on the version reg.exe utility works differently. v5.1.x.x
(that I have on my XPSP3) works correctly, but v5.2.x.x does not work
as it is expected to work.

>"reg import" command:
>- when v5.1: returns "Operation completed successfully" to standard
OUTPUT stream
>- when v5.2: returns "Operation completed successfully" to standard
ERROR stream

>Moreover, it is probably a problem with PowerShell also :(
>PowerShell treats these streams differently and process ERROR stream
messages as errors. Which is correct imho.
ferventcoder added a commit that referenced this issue Jun 13, 2015
* stable:
  (GH-249) Fix "operation completed successfully" on stderr
  (maint) ApplicationParameters are readonly
  (maint) remove spec logging
@ferventcoder ferventcoder self-assigned this Jun 13, 2015
@ferventcoder
Copy link
Member

Fixed in 9936876 and will be released with 0.9.9.7.

@ferventcoder
Copy link
Member

See #445 - the code for this is being reverted with #8 as now by default choco doesn't fail based on stderr being written to and we want both paths to be similar (choco's built-in powershell and system powershell).

ferventcoder added a commit to ferventcoder/choco that referenced this issue Jan 1, 2016
When running PowerShell operations, use a built-in PowerShell host by
default, allowing fallback to the older method of running Posh
by calling an external process. By building against the oldest version
of System.Management.Automation that aligns with the oldest Windows
Operating Systems supported, we can guarantee this will work on every
version of Windows where Chocolatey is supported.

In case we do run into issues, attempt to resolve the PowerShell
assemblies starting from the newest version and falling down to the
older versions until one is resolved or no version is resolved. There
is a known assembly that will go through this process every time -
System.Management.Automation.resources, en-US. To see those assemblies
go through, one must ask for both debug and verbose output.

This reverts the changes for chocolateyGH-249 in 9936876 and the changes
from chocolateyGH-349 in 344268b so that both paths (system powershell
and choco's built-in PowerShell) run with similar output and because by
default in d523e7b (chocolateyGH-445) choco no longer fails on the
presence of stderr output.
@BrainSlugs83
Copy link

BrainSlugs83 commented Jun 24, 2018

I have no idea what Choco is -- and I apologize for derailing -- but this bug report is the top google search result for reg stderr (was trying to figure out why a PowerShell script was failing) -- I thought I'd share this in case it helps others (it's a dirty hack, but it works):

function Import-Reg($path)
{
    # This is necessary because some versions of reg.exe return their
    # success messages on the error stream! :(

    $cmd = [String]::Concat('reg import "', $path, '" 2>&1');
    $output = & cmd.exe /c $cmd

    $output = [String]::Concat(($output | % { $_.ToString() })).Trim();

    if ($output -ilike "*success*")
    { 
        echo $output;
    }
    else
    {
        throw $output;
    }
}

And usage is pretty simple:

Import-Reg .\MyRegFile.reg;

Hope that's helpful for someone, somewhere. :)

@travis-dr
Copy link

Thank you @BrainSlugs83 that has come in helpful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants