choco.exe.manifest is ignored because it is extracted AFTER first choco.exe access #1292
Comments
ferventcoder
changed the title
|
This is likely related to #1178, which had a fix for Windows 10. |
I believe that you are likely running from Windows 2016, but for some reason it is coming back as 6.2. What does the following run in PowerShell give you? [System.Environment]::OSVersion.Version |
|
PS C:\Windows\system32> [System.Environment]::OSVersion.Version Major Minor Build Revision 10 0 14393 0 |
|
On the same Server after upgrading from .3 to .5: Information.PlatformVersion='10.0.14393.0'| Information.PlatformVersion='6.2.9200.0'| |
|
In Chocolatey v0.10.4, we externalized the app.manifest - #1054. I wonder why it comes back incorrectly with choco... We added the compatibility into the app.manifest so it would show correctly quite a long time ago - https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx | Can you verify that this file exists: |
|
The .NET Framework calls https://msdn.microsoft.com/en-us/library/windows/desktop/ms724833(v=vs.85).aspx and https://msdn.microsoft.com/en-us/library/windows/desktop/ms724834(v=vs.85).aspx which should come back with the right information. |
|
Actually, I'm guessing that the manifest isn't getting applied for some reason - can you verify this is correct? |
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="choco.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
Specifying requestedExecutionLevel node (below) will disable file and
registry virtualization.
Set level to "asInvoker" when you want choco to run under the context
of the user invoking. This is the same as Chocolatey behavior prior
to 0.10.4.
Set level to "requireAdministrator" to only allow administrators to
run Chocolatey.
Set level to "highestAvailable" to allow non-admins to run in
non-administrative context, but require administrators to always run
with administrative privileges. This is the recommended and default
behavior of Chocolatey v0.10.4+.
NOTE: Currently you will need to make this change every time
Chocolatey is re-installed or upgraded (every new version). At least
for now - https://github.com/chocolatey/choco/issues/1206
The following is an unsupported use case: If you want to utilize File
and Registry Virtualization for backward compatibility then delete
the requestedExecutionLevel node.
-->
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 10 / Windows Server 2016 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
<!-- Windows 8.1 / Windows Server 2012 R2 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!-- Windows 8 / Windows Server 2012 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!-- Windows 7 / Windows Server 2008 R2 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!-- Windows Vista / Windows Server 2008 -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
</application>
</compatibility>
</asmv1:assembly> |
|
How can i verify if the manifest is getting applied or not? |
|
Put an error in the file. Like "1" at the very start of the file and save it. I just did that and I got the following: choco
Unhandled Exception: System.ComponentModel.Win32Exception: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at shim.CommandExecutor.execute(String process, String arguments, String working_directory, Boolean is_gui, Boolean wait_for_exit, Boolean requires_elevation)
at shim.ShimProgram.Main(String[] args) |
1
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="choco.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
Specifying requestedExecutionLevel node (below) will disable file and
registry virtualization.
Set level to "asInvoker" when you want choco to run under the context
of the user invoking. This is the same as Chocolatey behavior prior
to 0.10.4.
Set level to "requireAdministrator" to only allow administrators to
run Chocolatey.
Set level to "highestAvailable" to allow non-admins to run in
non-administrative context, but require administrators to always run
with administrative privileges. This is the recommended and default
behavior of Chocolatey v0.10.4+.
NOTE: Currently you will need to make this change every time
Chocolatey is re-installed or upgraded (every new version). At least
for now - https://github.com/chocolatey/choco/issues/1206
The following is an unsupported use case: If you want to utilize File
and Registry Virtualization for backward compatibility then delete
the requestedExecutionLevel node.
-->
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 10 / Windows Server 2016 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
<!-- Windows 8.1 / Windows Server 2012 R2 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!-- Windows 8 / Windows Server 2012 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!-- Windows 7 / Windows Server 2008 R2 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!-- Windows Vista / Windows Server 2008 -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
</application>
</compatibility>
</asmv1:assembly>C:>choco list -localonly There is no error.. |
|
If you can do that and verify, that will help. If it is getting applied but that section is being ignored, that is going to require a LOT more research. Of note, one article turned up a timestamp possibly causing the issue (but the timestamp changes when the file is built): |
|
What do you get for these next two commands?
|
|
C:>where.exe choco |
|
C:>choco list -lo --shimgen-log |
|
Well it means it is completely ignoring that file. Can you verify the casing of the manifest and the exe are exactly the same? |
ferventcoder
changed the title
|
I don't know what you mean, please explain... |
|
In |
|
|
|
@Outek That manifest file looks suspect - please turn on "Show file extensions" and ensure that file doesn't end in ".txt". |
|
Better yet, provide the output of:
Thanks |
Directory of C:\ProgramData\chocolatey 12.05.2017 23:04 .12.05.2017 23:04 .. 12.05.2017 23:03 bin 12.05.2017 23:02 7'499'400 choco.exe 12.05.2017 23:02 0 choco.exe.ignore 12.05.2017 23:45 2'626 choco.exe.manifest 12.05.2017 23:04 config 12.05.2017 23:03 helpers 27.03.2017 22:02 lib 12.05.2017 23:02 670 LICENSE.txt 27.03.2017 20:42 logs 12.05.2017 23:03 redirects 12.05.2017 23:03 tools 4 File(s) 7'502'696 bytes 9 Dir(s) 27'873'824'768 bytes free |
|
This is very strange |
|
@Outek can you prove the output of the following:
|
|
PS C:> ls HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide Configuration PS C:> Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide |
|
Nothing there looks out of line. We are looking into options in #1307 and may embed the manifest back into choco. |
Here are links where a Microsoft developer writes about caching of the manifest information: https://blogs.msdn.microsoft.com/junfeng/2006/10/25/touch-the-exe-after-you-added-a-manifest-for-it-in-vista/ The issue is caused by the way choco.exe.manifest is deployed. Currently, it is unpacked by choco.exe itself, not by the Chocolatey installation script. This leads to the following sequence of events:
And, possibly, later:
The solution is to move the manifest deployment logic to the install script. To avoid unconditionally overwriting the existing manifest upon chocolatey.nupkg extraction, the file in the nupkg could be named, for example, |
|
What has apparently changed from Vista times (when those blog posts were written) is that the cache seems to survive reboots. |
|
I think we have a bug:
The file should be already set. I think you have found a bug. |
|
@Outek can you confirm if you change the last modified time of choco.exe that it starts working appropriately? |
|
Yes, i can confirm this. After the last modified time is altered: ForceDependencies='False'|Information.PlatformType='Windows'| |
If the `choco.exe.manifest` file is not present on first use of choco.exe, it extracts the file. However Windows will have already cached that choco.exe doesn't have a manifest and will not recheck until the choco.exe changes (last modified time) as it caches that it doesn't have a manifest. To force a recheck, someone would need to "touch" the file to change the last modified date. The issue comes down to the fact that a manifest file needs to be in place when choco is installed, before the first time that `choco.exe` gets called. Ensure that the manifest file is packaged up and it will be unpacked automatically next to choco at the right time.
* pr1264: (26 commits) (maint) COMMITTERS - EOL change to CRLF (doc) update CONTRIBUTING/COMMITTERS (GH-1241) XmlService - trace logging information (maint) formatting (GH-1241) FileSystem - move file creates directory (GH-1241) Explicitly handle closing (maint) formatting (GH-1292) Ensure manifest extracted on unpackself (log) replace_file use new lines for log (maint) update CHANGELOG / nuspec (maint) nuspec - add info links to description (maint) clean up lib nuspec (GH-1311) Install-ChocolateyPowershellCommand File/FileFullPath aliases (GH-1284) ensure file/filefullpath on functions (maint) ReadMe updates (GH-1241) Use process id with update file (maint) restrict list start/end messages to log file (GH-1309) Restrict trace output (GH-1241) More Robust File.Replace (GH-1241) Use write_file for stream writing ...
* stable: (26 commits) (maint) COMMITTERS - EOL change to CRLF (doc) update CONTRIBUTING/COMMITTERS (GH-1241) XmlService - trace logging information (maint) formatting (GH-1241) FileSystem - move file creates directory (GH-1241) Explicitly handle closing (maint) formatting (GH-1292) Ensure manifest extracted on unpackself (log) replace_file use new lines for log (maint) update CHANGELOG / nuspec (maint) nuspec - add info links to description (maint) clean up lib nuspec (GH-1311) Install-ChocolateyPowershellCommand File/FileFullPath aliases (GH-1284) ensure file/filefullpath on functions (maint) ReadMe updates (GH-1241) Use process id with update file (maint) restrict list start/end messages to log file (GH-1309) Restrict trace output (GH-1241) More Robust File.Replace (GH-1241) Use write_file for stream writing ... # Conflicts: # CONTRIBUTING.md # README.md
|
@Outek awesome. Thank you! |
ferventcoder
changed the title
|
Sorry - just getting wind of this now. I believe this is a bug in windows manifest caching (because the SDK says it should not get stuck like this) and I found changing the EXE modified date is the least destructive away around it. Blogged it ages ago: http://csi-windows.com/blog/all/27-csi-news-general/245-find-out-why-your-external-manifest-is-being-ignored |
Windows behavior of manifest caching is enough to make even the best of admins and developers want to tear out their hair until they realize there is a cache and changes to the manifest are completely ignored by Windows. So leave a breadcrumb here so that folks know if they make a change to the manifest file, they will need to "touch" the file they are trying to get the manifest to take effect for - in this case choco.exe. The modification date will need changed to clue Windows in that there is a new manifest. This is only when changing the file AFTER the exe / modification date has been run even once. It's better to just say to always update the modification date as someone may not know whether the file has been ran before.
* stable: (chocolateyGH-1131) logging: better defaults for ERROR (chocolateyGH-1131) logging: better defaults for WARN (chocolateyGH-1131) logging: better defaults for INFO (chocolateyGH-1665) sign init.ps1 file (doc) More info on license next steps (chocolateyGH-1503) Warn on incorrectly named license file (chocolateyGH-1292) add note on manifest caching
What You Are Seeing?
If i try to push a package to the nuget server with the parameter -debug the wrong os version is logged.
What is Expected?
Platformversion = 10.x
Platformname = Windows Server 2016 or something similar
How Did You Get This To Happen? (Steps to Reproduce)
choco push <packagename.nupkg> --api-key= -source -debug
Output Log
The text was updated successfully, but these errors were encountered: