Crash Reports

Rhino Developer
22

Hi @nathanletwory - they are all in a ZIP file I send prior to the crash dump.

Paul

23

I downloaded both uploads and they both are the same crashdump zip at least according the system, it looks like our upload system got somehow wires crossed. Could you please re-upload the plugin files archive?

24

Done - thanks @nathanletwory

25

Thanks, these contain plug-in files! It looks that these are from a newer version 2021.1.5.133, whereas the crashdump has been created from a version 2021.1.4.132. Let me try with these though.

26

The version number got changed - but the actual code should be the same @nathanletwory. However - it’s always possible I messed this up. I have 20+ versions of the plugin being used by users (and for each version there is an Enterprise, Studio and Demo build), so actually keeping track of all this is non-trivial. I have source code for 2021.1.4.132, so I can do a direct build on that code.

How does Visual Studio determine that the crash dump matches the .RHP?

Paul

27

Hi @nathanletwory

I have rebuilt the plugin with the exact codebase that would have be used for the dump file you have - and re-loaded it. Sorry for the previous version. I still however get the same error “no binaries loaded for OctaneRenderForRhino.rhp”

Thanks

Paul

28

‘RhinoCrashDump.dmp’ (CLR v4.0.30319: DefaultDomain): Loaded ‘*C:\Users\castr\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins\OctaneRenderForRhino (f109bd23-4cf3-4c0b-9f83-06be474b0152)\2021.1.4.132\RHI Installer 7\Rhino 7.0\x64\OctaneRenderForRhino.rhp’. No matching binary found.

The Windows username is different to mine - so is that the problem?

Paul

29

That shouldn’t matter. I think there is the need to set up a symbol store. I’m reading through the documentation and will try to figure out steps for you to replicate.

We get all the time crashdumps with plug-ins installed in all sorts of places, the symbol store helps the debugger cope with that. I’m not sure why I can’t select the RHP locally, but I’m hopeful that with a symbol store it will be possible. Lets hope that the recompiled version is enough for the symbol store and the debugger to load that from the symbol store.

It’ll take a while for me to get this done and tested, but hopefully by (my) tomorrow I’ll have some useful results.

edit: adding info as I go through the docs and attempts

From the page SymStore - Windows drivers | Microsoft Learn I read

SymStore stores symbols in a format that enables the debugger to look up the symbols based on the time stamp and size of the image (for a .dbg or executable file), or signature and age (for a .pdb file).

This leads me to believe that the newly built binaries won’t necessarily work, still have to try though.

30

Thanks @nathanletwory

31

Steps I have taken:

  1. Create a folder somewhere for the symbol store. I put mine on D:\ and called it symstore: D:\symstore
  2. Install Windows Debugging Tools:
    1. Follow instructions on Download Debugging Tools for Windows - WinDbg - Windows drivers | Microsoft Docs. From the Windows SDK installer you need to select only the debugger tools
    2. add the path where symstore.exe is located to PATH. For me symstore.exe is located at C:\Program Files (x86)\Windows Kits\10\Debuggers\x64.
  3. Add your DLLs, binaries and PDB files to your symbol store: symstore add /r /f *.* /s D:\symstore /t "Octane Plugin". Note that for this particular usage I cd'd into the folder where the dlls, rhps and pdb are located
    1. repeat this step for each and every version of your plug-in that you have. According the documentation this has to be the binaries that you release, including the PDB file
  4. Debug a crashdump, add the symbol store to the paths for the debugger

Assuming dates, sizes and such correspond the debugger will find the correct file from the symbol store. You can check the symbol store to see how your data is stored.

Since I don’t have the exact same binaries I can’t fully test properly, but for instance the octane.dll is found, there is just no PDB for it.

Please also read through the SymStore documentation: Using SymStore - Win32 apps | Microsoft Docs and SymStore Command-Line Options - Win32 apps | Microsoft Docs

32

Thanks for the huge amount of effort you have put into this @nathanletwory - I very much appreciate it.

I did as you suggested…

C:\Users\Paul\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins\OctaneRenderForRhino (f109bd23-4cf3-4c0b-9f83-06be474b0152)\2021.1.4.132\RHI Installer 7\Rhino 7.0\x64>“\Program Files (x86)\Windows Kits\10\Debuggers\x64\symstore” add /r /f . /s c:\symstore /t “Octane Plugin”
Finding ID… 0000000001

SYMSTORE: Number of files stored = 5
SYMSTORE: Number of errors = 0
SYMSTORE: Number of files ignored = 1

And I added my symstore folder to the symbols path in Visual Studio. However I still get:

‘RhinoCrashDump.dmp’ (CLR v4.0.30319: DefaultDomain): Loaded ‘*C:\Users\castr\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins\OctaneRenderForRhino (f109bd23-4cf3-4c0b-9f83-06be474b0152)\2021.1.4.132\RHI Installer 7\Rhino 7.0\x64\OctaneRenderForRhino.rhp’. No matching binary found.

Then to absolutely be certain, I downloaded the 2021.1.4.132 enterprise build (the actual Release build where the crash originated from) from OTOY Forums • View topic - OctaneRender 2021 for Rhino (TEST and STABLE), added the files to the symstore. In this case, it gave the following:

(Minidump): Loaded ‘C:\Users\Paul\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins\OctaneRenderForRhino (f109bd23-4cf3-4c0b-9f83-06be474b0152)\2021.1.4.132\RHI Installer 7\Rhino 7.0\x64\OctaneRenderForRhino.rhp’.

‘RhinoCrashDump.dmp’ (CLR v4.0.30319: DefaultDomain): Loaded ‘C:\Users\Paul\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins\OctaneRenderForRhino (f109bd23-4cf3-4c0b-9f83-06be474b0152)\2021.1.4.132\RHI Installer 7\Rhino 7.0\x64\OctaneRenderForRhino.rhp’. Cannot find or open the PDB file.

In this case, the RPD file is in the same folder as the .RHP file. I guess because the .RHP file is a Release build, it cannot find a .PDB file?

I am trying to find the function call that caused the crash, but the call stack is not helpful…

> octane.dll!00007fff4f5989c9() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4f594fef() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4f586eeb() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4f59ee42() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4f59ed53() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4f588d38() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4f55fdae() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4e17a9ec() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4ec2f65a() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4ec2ee88() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4ec2d293() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4e6a90fc() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4e6a4d24() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4e6a74d7() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4ea084cf() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4e9d8b3f() Unknown Non-user code. Binary was not built with debug information.
octane.dll!00007fff4e39e3c7() Unknown Non-user code. Binary was not built with debug information.
OctaneWrapperEnterprise.dll!00007fffdf72f75c() Unknown Non-user code. Binary was not built with debug information.

I do not want to release a Debug build just to get a call stack.

Thanks

Paul

33

If you check your symbol store do you see a folder entry for the plug-in PDB? Note that the PDB should be the one created for the exact build you added, a PDB from a different build date most likely wont work.

kuva
kuva1214×576 110 KB

You don’t need to create a debug build, but you do have to turn on debug information for release builds for this to work properly.

For instance the linker settings in one of our released binary files looks like this

    <Link>
      <SubSystem>Windows</SubSystem>
      <GenerateDebugInformation>true</GenerateDebugInformation>
      <RegisterOutput>false</RegisterOutput>
    </Link>

The GenerateDebugInformation is the most important part here.

34

Thanks Nathan

It looks like to progress this I will need to do another release, and store the PDB file used in that release for future debugging. I will post back here once I have the results from this. Thanks again for the work you have put into this. I sounds like the instructions at Rhino - Crash Dump Analysis need revising based on the information you have provided.

Paul

35

The instructionsin the mentioned analysis guide should still work for the simple case, and I think the guide is mostly geared towards inspecting crash dumps while developing locally. Once you get in the territory of releasing multiple versions it is easier to maintain a symbol store where you add binaries, dlls, rhps and pdbs for each version just prior to releasing them.