Rhiexec fails to install plugin, on just one machine


We have one machine where our installer’s call to rhiexec to install our plugin fails. The following is the very short contents of the rhiexec log file.

Could you give us a hint what might be going wrong?

09/14/2016 15:27:11    25860    Info    Start: rhiexec
                    version 6.0.16250.12021
                    unknown Enterprise  6.2.9200.0
09/14/2016 15:27:11    25860    Info    arguments: 
                    "C:\Program Files\NVIDIA Corporation\Iray For Rhino 6\IrayForRhino6.rhi"
09/14/2016 15:27:11    25860    Info    Logging started: 2016/09/14 15:27:11
09/14/2016 15:27:11    25860    Debug    Unknown    InstallerDialog_Load starting    (0%)
09/14/2016 15:27:11    25860    Debug    Unknown    InstallerDialog_Load ending    (0%)
09/14/2016 15:27:11    25860    Info    Initializing    INIT START:     (0%)
09/14/2016 15:27:11    25860    Error    Exception: System.ArgumentException
                    Message: 1 is not a supported code page.
                    Parameter name: codepage
                    Source: mscorlib
                    StackTrace:    at System.Text.Encoding.GetEncoding(Int32 codepage)
                       at ICSharpCode.SharpZipLib.Zip.ZipFile.ReadEntries()
                       at ICSharpCode.SharpZipLib.Zip.ZipFile..ctor(String name)
                       at RhiExec.Package.OpenZipFile(String filename)
                       at RhiExec.Package.get_Files()
                       at RhiExec.Package.FindFiles(Regex expression)
                       at RhiExec.Package.FindSingleFile(String pattern)
                       at RhiExec.InstallerPlatformSpecific.ContainsRecognizedPayload(AsyncReporter progress)
                       at RhiExec.Installer.Create(String packagePath, AsyncReporter progress)
                       at RhiExec.Engine.Engine.Init(String packagePath, AsyncReporter progress)
                       at System.Threading.Tasks.Task`1.InnerInvoke()
                       at System.Threading.Tasks.Task.Execute()
                    --- End of stack trace from previous location where exception was thrown ---
                       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
                       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
                       at RhiExec.View.InstallerDialog.<InstallerDialogShown>d__3.MoveNext()
09/14/2016 15:27:11    25860    Debug    Unknown    InstallerDialogClosing starting    (0%)
09/14/2016 15:27:11    25860    Debug    FinalExit    Exiting installation with return code Initializing
09/14/2016 15:27:11    25860    Info    Logging ended: 2016/09/14 15:27:11
09/14/2016 15:27:11    25860    Info    Uploading this log file
09/14/2016 15:27:11    25860    Warning    C:\Program Files\McNeel\Rhino Installer Engine\x64\..\RmaErrorReporting.exe not found

It looks like this is happening inside the library that unzips the RHI file to inspect it’s contents.

Are there any files in the RHI archive that have names that use non-ASCII characters? It looks like on that target machine, the zip archive can’t be read because something about it cannot be decoded using whatever code page was selected.

What’s weird is that it says 1 is not a supported code page - but 1 is a strange code page ID - I’m used to seeing numbers in the thousands for code pages.

The same files work on my machine, both are Win 7 Enterprise SP1. Here are the files:

09/14/2016  03:14 PM         1,438,720 avcodec-56.dll
09/14/2016  03:14 PM           139,776 avfilter-5.dll
09/14/2016  03:14 PM           240,640 avformat-56.dll
09/14/2016  03:14 PM           359,424 avutil-54.dll
09/14/2016  03:14 PM         5,258,752 AxFDecoding.dll
09/14/2016  03:14 PM           681,984 axf_importer.dll
09/14/2016  03:14 PM           757,760 blend_render.dll
09/14/2016  03:14 PM           206,336 cb_importer.dll
09/14/2016  03:14 PM           231,936 ct.dll
09/14/2016  03:14 PM           314,176 cudart64_65.dll
09/14/2016  03:14 PM           524,288 dds.dll
09/14/2016  03:14 PM           196,096 DPGL.dll
09/14/2016  03:14 PM            17,408 DPUI.dll
09/14/2016  03:14 PM           138,752 DPUtil.dll
09/14/2016  03:14 PM           251,392 ffmpeg_video_decoder.dll
09/14/2016  03:14 PM         8,821,736 FlxCore64.dll
09/14/2016  03:14 PM         3,874,304 freeimage.dll
09/14/2016  03:14 PM        11,836,928 gen_llvm.dll
09/14/2016  03:14 PM           364,032 glew32.dll
09/14/2016  03:14 PM           205,312 Iray.dll
09/14/2016  03:14 PM            24,576 IrayForRhino.rhp
09/14/2016  03:14 PM           509,952 iray_bridge_client.dll
09/14/2016  03:14 PM           514,560 iray_bridge_server.dll
09/14/2016  03:14 PM        97,907,712 libiray.dll
09/14/2016  03:14 PM        54,089,728 libirt.dll
09/14/2016  03:14 PM        48,448,512 libneuray.dll
09/14/2016  03:14 PM         5,497,344 libogl.dll
09/14/2016  03:14 PM           560,128 license_manager.dll
09/14/2016  03:14 PM             4,608 MDLMaterials.dll
09/14/2016  03:14 PM         1,118,720 mi_exporter.dll
09/14/2016  03:14 PM         1,701,376 mi_importer.dll
09/14/2016  03:14 PM             7,168 Native.dll
09/14/2016  03:14 PM           304,640 nvcuvid_video_decoder.dll
09/14/2016  03:14 PM         8,571,904 optix_prime.1.dll
09/14/2016  03:14 PM            22,528 RiXCore.dll
09/14/2016  03:14 PM           297,472 RiXGL.rdr
09/14/2016  03:14 PM           308,736 screen_video.dll
09/14/2016  03:14 PM           105,984 swresample-1.dll
09/14/2016  03:14 PM           457,216 swscale-3.dll

All use letters, numbers, ‘-’, ‘_’ and ‘.’

I searched around, and found this:


Is it possible that the fix of setting the default sharpziplib codepage to 0 would help in rhiexec?

It turns out that the machine in question has standard the English-US codepage, but he uses an Apple 104 (?) key keyboard (http://www.apple.com/shop/product/MB110LL/B/apple-keyboard-with-numeric-keypad-english-usa) for input, and I wonder if this confuses things, or maybe it is the English-Europe part?

By the way, he does not have this trouble with Rhino 5. For Rhino 5, we grab the rhiexec from its installation, whereas for Rhino 6, we have switched to looking up the location of the utility in the registry.

Changing the Format for the current user from English-Europe to English-US makes it work, but in general, this is not a terribly satisfying fix, since the format is then wrong, for a European user. Are you able to fix this somehow?

You’re suggesting that we set ZipConstants.DefaultCodePage = 0; right?

I built a test version of rhiexec.exe that has that set (attached (830.6 KB)), so we can see how it works. I’m a bit nervous to put this out in the wild, because we use rhiexec.exe to unpack translated resources for Rhino.

You’ll need to unpack this zip file into the C:\Program Files\Rhinoceros 5\System folder to test it. Note that this is built from the Rhino 6 source, and so it might require a newer version of the .NET framework to be installed in order to run.

How are you creating the Zip file? I wonder if the archive has its code page set properly in it?

If you have the Rhino WIP installed on the user’s computer, then you need to put this in
C:\Program Files\McNeel\Rhino Installer Engine

We will test it first. If it works, we can think about if it makes sense to put it in the release :slight_smile:

Codepage 0 is meant to mean the current ANSI page, as far as I can tell, which gets around certain situations. I am no codepage expert, so I do not know what would happen if a Chinese company makes a plugin using rhiexec to install, with filenames with Chinese characters, for example. Probably not good things. Codepage 0 could make sense as a fallback attempt in case of error though.

Btw, the codepage for English-Europe is something added after Windows 7, i.e. relatively new. Maybe there is something which could be done to support it directly. Anyway, my colleague changed the setting on his machine, so the installer works for now.

I will let you know when we have tested it.

@CarstenW – I think this should fixed in the latest WIP. I recently incorporated SharpZipLib’s fix to improve invalid codepage handling. I included this same fix in Rhino 5 (since SR12), which seems to be working for you (unfortunately, I forgot to port the fix to Rhino WIP until now).

Of course, please let me know if the latest WIP doesn’t fix things for you and we’ll take a closer look.

/cc @brian

@will Let’s keep an eye on this. If we can’t seem to reliably make RHI files work using the PKZIP format (that’s what SharpZipLib implements), maybe we should consider supporting an additional compression algorithm for .RHI files. PKZip, unfortunately, is ancient - and like many ancient things, doesn’t do a good job of communicating the code page used to make the archive.

Sure. If it happens again, we should see it in raygun :+1:

Brilliant, thanks for this. Sorry that I never got back to you, the developer who has the problem is meant to test the fix, but he has switched codepages and is swamped, so he didn’t get to it yet.