Question Best way to debug without entry-points in the exception strings

Since we updated to 1.6.0, we no longer get entry-points in our logs after a build crash, due to this update:

Exception strings no longer contain the entry-point name of the job/function-pointer that caused the throw. This change was required because the Burst compiler has to produce deterministic results from any given compile, which is fundamentally opposed to per-entry-point function derivations.
​

So instead of a medium helpful exception that at least points us to the job:

System.ArgumentOutOfRangeException:
Thrown from job: StatusEffectBufferSystem.CountdownStatusEffectsJob
This Exception was thrown from a job compiled with Burst, which has limited exception support. Turn off burst (Jobs -> Burst -> Enable Compilation) to inspect full exceptions & stacktraces. In this standalone build configuration burst will now abort the Application​

We now get even less information:

System.ArgumentOutOfRangeException:
This Exception was thrown from a job compiled with Burst, which has limited exception support. Turn off burst (Jobs -> Burst -> Enable Compilation) to inspect full exceptions & stacktraces. In this standalone build configuration burst will now abort the Application.​

This post covers looking into the stack trace and pulling an ID that you can then use in lib_burst_generated.txt to get the job, but we're not seeing ID's like in the original post (see the followup question at the bottom about Ordinal0). I was just curious if this is the only method for tracking down exceptions, or if there was another less circuitous route that we're just missing?

Also if anyone knows, is there a plan to be able to get at least the entry point back into the exception? Or is that off the table at this point?

 

Also noticing that sometimes we get readable information in the stack trace:

========== OUTPUTTING STACK TRACE ==================

0x00007FFE2F5F56C9 (UnityPlayer) UnityMain
0x00007FFE2F5F4CCA (UnityPlayer) UnityMain
0x00007FFE2E6AA03C (UnityPlayer) UnityMain
0x00007FFE45625D0E (lib_burst_generated) [C:\Users\<user>\Documents\<game>\unknown\unknown:0] Unity.Jobs.IJobForExtensions.ForJobStruct`1<StatusEffectBufferSystem.CountdownStatusEffectsJob>.Execute
0x00007FFE2E6A842B (UnityPlayer) UnityMain
0x00007FFE2E6A8654 (UnityPlayer) UnityMain
0x00007FFE2E6A8B46 (UnityPlayer) UnityMain
0x00007FFE2E690E09 (UnityPlayer) UnityMain
0x00007FFE2E693152 (UnityPlayer) UnityMain
0x00007FFE2E69874C (UnityPlayer) UnityMain
0x00007FFE2EA64F3D (UnityPlayer) UnityMain
0x00007FFEAAEC7034 (KERNEL32) BaseThreadInitThunk
0x00007FFEAB002651 (ntdll) RtlUserThreadStart

========== END OF STACKTRACE ===========

And other times we don't?

========== OUTPUTTING STACK TRACE ==================

0x00007FFC2C7A56C9 (UnityPlayer) UnityMain
0x00007FFC2C7A4CCA (UnityPlayer) UnityMain
0x00007FFC2B85A03C (UnityPlayer) UnityMain
0x00007FFC273DA5B5 (lib_burst_generated) Ordinal0
0x00007FFC273D978B (lib_burst_generated) Ordinal0
0x00007FFC273D94F1 (lib_burst_generated) Ordinal0
0x00007FFC2B85842B (UnityPlayer) UnityMain
0x00007FFC2B858C56 (UnityPlayer) UnityMain
0x00007FFC2B840E0D (UnityPlayer) UnityMain
0x00007FFC2B843152 (UnityPlayer) UnityMain
0x00007FFC2B84874C (UnityPlayer) UnityMain
0x00007FFC2BC14F3D (UnityPlayer) UnityMain
0x00007FFC8EF954E0 (KERNEL32) BaseThreadInitThunk
0x00007FFC8F1E485B (ntdll) RtlUserThreadStart

========== END OF STACKTRACE ===========

I'm trying to track down the differences to sort out why we get that information sometimes and not others, but if anyone can shed light on it that would be very helpful.