hi, one suggestion here I’ve wondered about. Can buildbot release debug builds as well as nightly? I think this is most useful. With debug builds accessible to general users they could have the ability to produce better bug reports?
Not sure that throwing resources at solving this problem in a slightly different way while this is already scheduled to land is the way to go there. but yeah technically we could make the build-bot output the symbols on windows if we wanted to.
For release builds probably something to consider at least for when we have crashpad integration working. We could then get nicer callstacks for crashes.
@jesterKing That’s handled on the server side with crashpad, there’s no need to ship symbols with the client.
Yes, that is what I meant (: I didn’t mean shipping with Blender itself, but just actually retaining the symbol files when they are created during build.
I guess it’s safe to assume that this is not going to make it into 2.82 since bcon3 is a week away?
This should have made it in before bcon2, so yeah you are correct.
yeah, sounds like a lot of planned 2.82 work had to be pushed back to keep on schedule so that’s not surprising. fingers crossed for 2.83!
OK @testure, forgive me if I’m not entirely clear about the issue…
But this is what I would aim for, right now.
Download the source for the exact version your team is running and build it with the configuration you feel is most useful. Make sure that a crash will create a core-dump.
Distribute the built binaries to your team. Give them instructions how to collect the core-dump, settings and blend-files so they can build an archive (tgz|zip…) an entire context to you.
Now your team should be able to run as usual and when a crash occur, just send you the core-dump.
You should be able to $gdb core and gdb> bt to get the stack-trace, as well as print out some context info.
Yes, I know I’m talking Linux here and you appear to be using Windows, but that should not stop you, right? 
@testure I see two problems here:
1.- your artists are not being able to reproduce the problem with proper steps, that makes impossible (or super super hard) to fix the problem, if they don’t deliver enough information to what they were exactly doing, and if they are unable to reproduce the crash, it makes no sense to try to do anything anyways, in our case when an artist have a crash before that artist continues working in the shot they have to dedicate 10 minutes to reproduce the problem, that way we know what was going on and what was the problem.
2.- Those artists probably don’t care about reporting bugs/crashes properly because they are used to the “it’s useless” situation with Maya, they need to learn that the difference with Maya is that if they got crashes (and Maya crash a lot more than blender, I know that for a fact) you won’t be able to fix anything, no matter if they reproduce the problem or not, it’s not a matter of explaining them that Blender is more stable, IMHO I think it’s a matter of pipeline stability and those artists should not be allowed to go back to Maya, because then when Maya crash they just assume it cannot be solved and they continue working, but the crash will still be there, and another thing related with maya/blender is that even IF Blender crashes, in a super rare case, when we use master build (built by us) and not release, we have practically never lost work, the auto save works so well that we never lost work, we cannot say the same for Maya/Max.
So IMHO those artist should not be allowed to go back but they should be teached on how to reproduce a problem for it to be solved, just a trace or a bug report won’t give any solution to the crashes, steps to reproduce the problem is needed (even for you), and if they suffer crashes they should work try to disable some addons or work with release, or give an exact list of addons they have enabled, RPR for example has caused some trouble here, even if it was not being in use.
Just my opinion, being director and td at our small studio 