[PUP-4333] Puppet package provider on windows fails if non-UTF8 characters are in Uninstall products name value Created: 2015/03/28  Updated: 2015/07/28  Resolved: 2015/07/28

Status: Closed
Project: Puppet
Component/s: Windows
Affects Version/s: PUP 3.7.5
Fix Version/s: PUP 3.8.1

Type: Bug Priority: Major
Reporter: Vormetric Labs Assignee: Unassigned
Resolution: Won't Fix Votes: 5
Labels: puppet-agent, windows
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Windows 7, 8, 8.1, 2008, 2012 with Puppet Agent 3.7.5

Issue Links:
relates to PUP-4924 Puppet Windows - Upgrading from 3.7.5... Closed


We have a handful of windows nodes that are experiencing an issue with the package provider being able to enumerate current packages.

"puppet resource package"

{ 'PackageName': ensure=> absent, provider => windows}


Here's an example error:

Could not prefetch package provider 'windows': U+00AE to IBM437 in conversion from UTF-16LE to UTF-8 to IBM437

Running "wmic product get name" returns all of the names appropriately, and some have odd non-ascii characters in it. Removing the odd looking characters based products from the registry resolves the issue.

Downgrading to 3.7.4 resolved the issue, which is odd, as i couldn't find where in the code path that a change was introduced that might cause this...

Comment by Josh [ 2015/05/03 ]

@Vormetric Labs, thanks for the tips. Ran into the same issue, and was able to workaround it by downgrading all clients to 3.7.4. So far, I've encountered issues with Microsoft language packs/proofing tools for Office (e.g. Microsoft Office Proofing Tools 2013 - Español) and Intel software (e.g. Intel Visual Fortran Compiler XE for Intel® 64). I'm surprised this isn't more widespread.

Comment by Vormetric Labs [ 2015/05/05 ]

Josh, yeah i'm not sure what got introduced in 3.7.5 that could have caused this behavior, but then i'm not intimate with this code, so can't seem to find the culprit. We also saw a lot of Office Proofing packs, and HP printer driver packages would have the same behavior.

Running "wmic product get name" will of course show the names and most of the systems with an out of place character are visible. I'm guessing puppet is trying to parse it and barfing. I'm also surprised it's not more wide spread. Seems 1 in 4 systems had some package in it that caused this problem. 3.7.4 doesn't exhibit this problem.

I guess we'll just stay with 3.7.4 until we are ready to jump into 4.X

Comment by Simon Wydooghe [ 2015/05/22 ]

I can confirm this issue. A quick peek through the list of applications shows Skype with the special trademark symbol next to it, this might be the culprit.

Comment by Eric Zhu [ 2015/06/28 ]

This issue still exists on 3.8.1. It's about Unicode support? In my case, the problem is Chinese characters in the program names.

false report. It seems it was fixed by 3.8.1

Comment by Jeff Sparrow [ 2015/07/06 ]

Is the work around for this to remove the non ascii characters from the registry? We are about to push out a large build, but we have a handful of servers running in to this issue. We do not have the time or resources to upgrade puppet as we are planning a larger 4.x upgrade soon. Wondering what the best work around is?

Edit: Even more so, what troubleshooting steps can I take, as I just noticed there are no nonascii characters in any return from wmic

Comment by Rob Reynolds [ 2015/07/28 ]

Please upgrade or move away from 3.7.5 immediately. You may have already received this message but we recalled v3.7.5 on Windows due to an incompatible Ruby being included. See https://groups.google.com/d/msgid/puppet-dev/CALCHMcQSPWJxby2ZZu1gs6JATuN9jmHgpTsw6NuO_m%3DzeNQ6Pg%40mail.gmail.com for details.

Comment by Rob Reynolds [ 2015/07/28 ]

Closing as this was an issue with Puppet 3.7.5 only, and related to the version of ruby that was included being incompatible with the 3.x series.

Generated at Thu Feb 27 00:51:27 PST 2020 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.