Category Archives: Troubleshooting

The case of the hrender that failed to start AdskLicensingAgent

Posted on by
Reply

Or, “things that happen when you use single-user licensing on a render node” 😉

In this case, a Houdini command-line render with Arnold (HtoA) failed because the AdskLicensingAgent failed to start.

---------------------------
AdskLicensingAgent
---------------------------
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: minimal, offscreen, webgl, windows.

---------------------------
OK  
---------------------------

After AdskLicensingAgent crashed, the render would continue, but license authorization would fail:

00:00:00   148MB         | authorizing with license manager: user ...
00:00:31   153MB WARNING | rendering with watermarks because of failed authorization:
00:00:31   153MB         |  [clm.v2] timeout before callback was called

Using Process Monitor, I saw (as expected) that the problem was that the AdskLicensingAgent was loading Qt platform plugins from Houdini:

The solution? Set QT_QPA_PLATFORM_PLUGIN_PATH to point to the AdskLicensingAgent\platforms folder.

set QT_QPA_PLATFORM_PLUGIN_PATH=C:\Program Files (x86)\Common Files\Autodesk Shared\AdskLicensing\Current\AdskLicensingAgent\platforms

Troubleshooting HtoA installs

Posted on by
Reply

If you have a problem like this:

  • HtoA does not show up in Houdini
  • the HtoA material nodes are missing
  • or you get node type errors such as
    • Failed to match node type definition
    • Error: bad node type found
    • Unknown operator on load

that is almost always because the environment (PATH and HOUDINI_PATH) is not set up correctly for HtoA and Houdini.

First, how to do you start Houdini? Don’t double-click on a hip file, because the Houdini environment won’t be set up correctly.

Second, what’s your houdini.env look like?
You want something like this (PATH is for Windows only):

# htoa config start
PATH = "$PATH;C:/arnold/htoa/htoa-5.6.0.0_r370661f_houdini-18.0.597/htoa-5.6.0.0_r370661f_houdini-${HOUDINI_VERSION}/scripts/bin"
HOUDINI_PATH = "C:/arnold/htoa/htoa-5.6.0.0_r370661f_houdini-18.0.597/htoa-5.6.0.0_r370661f_houdini-${HOUDINI_VERSION};&"
# htoa config end

Third, check Help > About Houdini > Show Details
You want to see the HtoA location at the start of HOUDINI_PATH

If you have other renderers and plugins, I would remove all other plugins from HOUDINI_PATH, get HtoA working, and then put the other stuff back.

If you need more help, please send support your houdini.env file (or json package if that’s what you’re using) and the Houdini info from Show Details.

signal caught: error C0000005 — access violation

Posted on by
Reply

People often ask me why they get this error…

Unfortunately, there’s no one answer. This is a totally generic error message, and it could be anything. Typically, it’s a bug somewhere. But where?

You could try to manually isolate it…is it shaders? textures? displacement? some object in the scene?

Ideally, you’ll be able to submit a Crash Error Report (CER). That would let us see where the crash actually happened.

Crash Error Report

The backtrace in an Arnold log won’t tell you, because we hide all the symbols in the shipping Arnold. So every backtrace comes out with things like Ordinal0 or AiLightsPrepare or AiADPDialogStrings, because those just happens to be the nearest unhidden symbols.

If you had a linux backtrace, we could symbolicate that on our end to see where the crash is happening. But on Window, it’s not so easy.

****
* Arnold 7.0.0.1 [5e3b4fd3] windows clang-10.0.1 oiio-2.3.2 osl-1.12.0 vdb-7.1.1 clm-2.0.0.235 rlm-14.1.3 optix-6.6.0 2021/11/18 13:08:38
* CRASHED in Ordinal0 at 00:00:00, pixel (946, 377)
* signal caught: error C0000005 -- access violation
*
* backtrace:
>> 0 0x00007ffb083cc387 [ai      ] Ordinal0
*  1 0x00007ffb08a24b56 [ai      ]
*  2 0x00007ffb0891cd0c [ai      ]
*  3 0x00007ffb087eaa92 [ai      ] AiLightsPrepare
*  4 0x00007ffb088ce771 [ai      ]
*  5 0x00007ffb088d4ef6 [ai      ]
*  6 0x00007ffb0870b67a [ai      ] Ordinal0
*  7 0x00007ffb09244186 [ai      ] AiADPSendPayload
*  8 0x00007ffb09243da3 [ai      ] AiADPSendPayload
*  9 0x00007ffb08db0a54 [ai      ] AiADPSendPayload
* 10 0x00007ffb09245414 [ai      ] AiADPSendPayload
* 11 0x00007ffb0989a74c [ai      ] AiADPSendPayload
* 12 0x00007ffb0989a8ed [ai      ] AiADPSendPayload
* 13 0x00007ffbd77c1bb2 [ucrtbase] configthreadlocale
* 14 0x00007ffbd8807034 [KERNEL32] BaseThreadInitThunk
* 15 0x00007ffbd9d22651 [ntdll   ] RtlUserThreadStart

Failed to register Arnold product

Posted on by
Reply

When you click Register in the Arnold License Manager, it runs the Autodesk tool AdskLicensingInstHelper. All Autodesk products use this tool to register themselves with Autodesk licensing.

Check the License Manager log

If you get Failed to register Arnold product, check the Arnold License Manager log.

On macOS:

  1. Open the Arnold License Manager.
  2. In the menu bar, click Arnold License Manager > About Arnold License Manager.
  3. In the About dialog box, click Show Log.
  4. Click Copy to copy the log, and send it to Autodesk licensing support.

On Windows:

  1. In the Arnold License Manager, click Help > About.
  2. Click Copy to copy the log.

If you want to try and troubleshoot the problem yourself, find the line that runs the AdskLicensingInstHelper register command. It will look something like this:

2021-11-08 11:13:10 DEBUG | [clmv2] run: "/Library/Application Support/Autodesk/AdskLicensing/Current/helper/AdskLicensingInstHelper" register --prod_key C0PL1 --prod_ver 2020.0.0.F --config_file /Applications/Autodesk/Arnold/mtoa/2022/license/pit/ArnoldConfig.pit --lic_method USER --eula_locale en_US

Under that line, there will be some log messages describing why the command failed.

Reinstall the licensing

In some cases, a complete uninstall and then re-install of “single-user licensing” can fix the problem.

In a Terminal, run these commands:

   cd ~/Autodesk/LicensingInstaller
   sudo ./uninstall.sh

sudo will ask you to type your password. Press ENTER after you finish typing.

Then start the Arnold License Manager and switch to Single-user licensing. The license manager will ask if you want to install single-user licensing.

The case of Maya and the missing ProductInformation.pit file

Posted on by
Reply

One of the strange thing about supporting Arnold at Autodesk is that you have to be a guru-level licensing expert on Autodesk licensing (not RLM, but Autodesk licensing).

In this case, Maya 2019 would silently fail at startup. Sometimes you’d see the splash screen, but then that would just disappear.

  • There was nothing in the Adlm.log
  • No MayaAdlm log was created
  • The MayaCLM log had only this: 
    ERROR: checkoutLicense: Failed to authorize license
  • The clm log did have this: 
    JsProductLicenseFact.loadSelectedProductInfoKey - Unable to get selected product key due to unknown problem.

TIP All these log files are in the Temp folder.

  • On Windows, look in %LOCALAPPDATA%\Autodesk\Logs
  • On OSX, look in $TMPDIR
  • On Linux, look in /var/tmp

Process Monitor confirmed that the ProductInformation.pit file was missing:

ProductInformation.pit is an all-important file used by the licensing infrastructure. Every Autodesk product must be registered in that pit file.

If ProductInformation.pit is missing, or corrupted, then everything stops working.

The case of the too-low OptiX version

Posted on by
Reply

In this case, when the user tried to render after enabling the OptiX denoiser, they got this error:

ERROR | [gpu] OptiX version 0.30.91 is lower than the minimum required version 5.0.0

This was with MtoA 3.0.1, which means Arnold 5.1.1.0

So, that means there is an incompatible version version of the OptiX library on the system, and it’s being loaded instead of the OptiX that ships with MtoA.

I probably could have just checked the PATH setting, but I used Process Monitor to absolutely sure, and I found this:

pml_furryball_optix

The problem is that another renderer added itself to the PATH. That’s a bad thing 😉

The solution? Remove that folder from PATH. Create a batch file or wrapper script to set the required environment when you start Maya to use the other software. Rather like the mtoa module file sets PATH when you start Maya.

NOTE In previous versions of MtoA, this would prevent MtoA from even loading.

[mtoa] Getting a Process Monitor log to troubleshoot problems loading mtoa

Posted on by
Reply

If a clean install of MtoA doesn’t work (and the computer does support SSE4.1), then “The specified module could not be found.” usually means there’s a missing dependency. Dependency Walker is a decent, if aging, tool for checking out dependencies, but for leaving no stone unturned, I prefer Process Monitor.

The MtoA plugin (mtoa.mll) depends on a handful of files only. Here’s the log of loaded DLLs for a working MtoA:

process_monitor_mtoa

Here’s a quick walkthrough (no audio) of how to get a Process Monitor log:

[MtoA] Error: defaultArnold Driver can’t create file

Posted on by
Reply

You’ll get an error like this if your project path has characters like é or ü or Ô in it.

// Error: [driver_exr] defaultArnoldDriver@driver_exr.RGBA: can't create file ".exr": OpenEXR exception: Permission denied. //

// Error: [driver_jpeg] defaultArnoldDriver@driver_jpeg.RGBA: can't create file ".jpg": Unable to open file ".jpg”

// Error: [driver_png] defaultArnoldDriver@driver_png.RGBA: can't create file ".png": Could not open file ".png"

Arnold can’t create the output file, because the special characters mess up the resolution of the output path, which ends up as an empty string.

So with no path provided, the ouput driver tries to write “.jpg” in the current working directory, which is probably something like C:\Program Files\Autodesk\Maya2018.

Use plain text characters for your project folders.

 

Tracking down the “error initialzing CLM (9)”

Posted on by
Reply

It’s not rocket science, but here’s a little application of the scientific method to technical support.

Observation

The Autodesk licensing system loads AdlmIntRes.xml

I used dtruss on macOS and Process Monitor on Windows to see what files are accessed by the licensing system. (On Linux, I would use strace)

On Windows, the file %LOCALAPPDATA%\Autodesk\Logs\AdlmIntRes.xml is loaded.

procmon_adlmintres

On macOS: $TMPVAR/AdlmIntRes.xml:

56944/0x16208b8:  stat64("/var/folders/vb/1d7zhsx97q7_ddz43nccbyj00000gn/T//AdlmIntRes.xml\0", 0x7FFF55D22F00, 0x0) = 0 0
56944/0x16208b8:  stat64("/var/folders/vb/1d7zhsx97q7_ddz43nccbyj00000gn/T//AdlmIntRes.xml\0", 0x7FFF55D22F30, 0x0) = 0 0
56944/0x16208b8:  open_nocancel("/var/folders/vb/1d7zhsx97q7_ddz43nccbyj00000gn/T//AdlmIntRes.xml\0", 0x0, 0x1B6) = 37 0

On Linux: /var/tmp/AdlmIntRes.xml

Hypothesis

Autodesk licensing will fail if there’s a problem with AdlmIntRes.xml

Testing

  • Delete AdlmIntRes.xml
    No problem. The file is recreated
  • Delete the contents of AdlmIntRes.xml and save the file.
    License authorization fails with the error [clm] error initialzing CLM (9)