Hello there,

We are trying to move our custom plugin to Houdini 16. Re-building with HDK16 goes fine, however when loading into Houdini 16 qt4 build for Windows, it would output version mismatch error like the one on sc1.jpg attched. After long hours of debugging we've found 2 things:

1) Houdini suppresses dll exceptions, so the actual dll causing the problem stays hidden. Btw is there a way to get more verbose DSO errors from Houdini?

2) After hacking this with a call to we found that this was coming from dbghelp.dll loaded from Houdini bin folder (see sc2.jpg). Renaming it did the job, so the one from C:\Windows\System32 gets loaded instead. This fixed the problem with the dso, however, I'm not sure if other problems won't arise.

So I guess my question is why do you need a custom version of this system .dll and how to work around this?

millag
1) Houdini suppresses dll exceptions, so the actual dll causing the problem stays hidden. Btw is there a way to get more verbose DSO errors from Houdini?

From http://www.sidefx.com/docs/hdk/_h_d_k__intro__debugging.html#HDK_Intro_Debugging_NotLoading [sidefx.com]

HDKdocs
What if my Custom Operators are not Loading into Houdini?

This is most likely due to a an error in the plugin library itself. Maybe an external library that your plugin requires is not referenced, or there might be missing symbols in the plugin, etc.

You can try setting the HOUDINI_DSO_ERROR environment variable. When HOUDINI_DSO_ERROR is set, Houdini prints out error messages for any custom dso's that did not load correctly.

I recommend setting it to 3 following the help at http://www.sidefx.com/docs/houdini/ref/env: [sidefx.com]

docs
Determines if DSO/DLL errors on plug-ins will be printed out to the console. This can help in debugging custom operators.

By default this is disabled.

The existence of the variable in the environment (or setting its value to 1) will cause dynamic linking errors to be output.

Setting the value to 2 will cause more verbose errors to be printed.

Setting the value to 3 will cause all DSO related messages to be printed.

millag
2) After hacking this with a call to

SetErrorMode(0)

we found that this was coming from dbghelp.dll loaded from Houdini bin folder (see sc2.jpg). Renaming it did the job, so the one from C:\Windows\System32 gets loaded instead. This fixed the problem with the dso, however, I'm not sure if other problems won't arise.

So I guess my question is why do you need a custom version of this system .dll and how to work around this?

This DLL is packaged to ensure that full symbol information can be found for stack traces. Certain debugging information generated by Visual Studio 2015 are not readable by the system dbghelp.dll's on Windows 7.

I don't understand why this is happening for you and only on the Qt4 build. Are you able to load say the SOP_Star.C HDK sample built with hcustom? My first thought would be something in your build process since I presume Houdini runs normally without your plugin.

I've been able to reproduce this with standard 16.0.504.20 build as well. Same issue when dbghelp.dll from Houdini bin folder is loaded. My best guess is dbgcore.dll does not load because of version mismatch. Note that our dso depends on a dll that makes calls to functions from dbghelp. I'll try to make a simple example that compiles with hcustom that reproduces the issue.

Best, Mila.