Access Violation RTTI Error when rendering
#1
We're experiencing a strange RTTI error when rendering with Redshift. It appears to be crashing Max during collecting of tyFlow/tyCache data.
I have also posted the logs on their forums here but wanted to keep you updated.
  • 3dsMax 2022
  • tyFlow 1.117
  • RS 3.6.04

It seems to only affect certain scenes and machines which makes it even more fun for us to diagnose! That being said, we've seen some luck with brute forcing the renders overnight, and some machines start rendering the jobs?!

Anyway, many thanks for any help with this.
[Image: 1725612748350-b9e45c05-7f74-457f-91a8-31...-image.png]


Attached Files
.zip   logs.zip (Size: 9.53 KB / Downloads: 27)
  Reply
#2
Do the machines generate a minidump when this happens?
  Reply
#3
(09-06-2024, 02:17 PM)tyFlow Wrote: Do the machines generate a minidump when this happens?

Yep, I have attached image of a possible reason


Attached Files Thumbnail(s)
   
  Reply
#4
Can you attach the actual minidump?
  Reply
#5
(09-06-2024, 04:01 PM)tyFlow Wrote: Can you attach the actual minidump?

here it is  Heart


Attached Files
.zip   3dsmax_minidump.zip (Size: 1.44 MB / Downloads: 30)
  Reply
#6
Hmm, it's crashing in a very bizarre location, which makes me think that some other memory corruption is happening and the location in code the memory dump is pointing to is a symptom not the cause.

Could you send me a few minidumps from a few separate crashes? That way I can check if they all point to the same location or not (the latter would confirm my theory above). So like, 4 or 5 separate dumps from separate crashes, if you have them.
  Reply
#7
Thanks Tyson, I will try to get those to you next week I expect.
Maxon have reproduced the error and suggest that it's Deadline's fault - "catching a message that should not be treated as an abort".
  Reply
#8
Hey Tyson, sorry we didn't get back to you.

3ds wasn't actively creating minidumps, so we've been stuck.

Our pipeline dev has been trying to debug it the last couple of days and they've attached to the process using WinDbg and managed to get a somewhat consistent stack trace, paired with the Redshift log cutting off early - while loading Tyflow objects from a certain setup. Please see images attached.
 
We're not really sure if tyFlow is the cause, but would appreciate any guidance, hopefully, something screams out to you from the images. (Note it's always the two tyFlow_2022_render!NodeAndAnims::SetNode+ at the same memory addresses if that means anything to you)


Attached Files Thumbnail(s)
       
  Reply
#9
I would need to see the minidumps to investigate further.

v1.119 will be out soon, so you can try that as well...
  Reply
#10
(11-08-2024, 05:43 PM)tyFlow Wrote: I would need to see the minidumps to investigate further.

v1.119 will be out soon, so you can try that as well...

Ok thank you. Here's a DMP from last week, it's massive - so I've zipped it.
https://we.tl/t-aSkxIKvzuf

Wer're in the process of getting more testing with 1.119 and generating a more recent DMP file for you.

Thank you!
  Reply
#11
Minidumps should be about 5-20mb in size. If yours is much larger, you're probably not grabbing it from the right place (you found a full dump not the minidump).

See the sticky about where to find minidumps.
  Reply


Forum Jump: