0

I'm investigating an "Access Violation" exception in my application (c++ native & CLI and .net). We installed the DebugDiag tool in production to capture dump files, but the issue is that the generated files are huge (30Gb+). And we're having trouble transferring those files between production servers and engineering team (often they got corrupted). Plus it's not a good idea to consume huge disk space on a production server.

I'm looking for a way to reduce the size of the dump files without loosing meaningful information (basically I need an accurate call stack with ideally the values of the local variables. I need to know the corrupted object then I can investigate how it may get corrupted).

Thanks.

Narendra
  • 1,511
  • 1
  • 10
  • 20
Baccarios
  • 1
  • 1
  • If you are generating Full Dump the only way is to compress it. – Vladimir Dronov Mar 25 '18 at 10:45
  • Usually dumps have quite good compression rate. But, maybe, you don't necessarily need Full Dumps? Try Mini dumps or just collect exception stacks into logfile. – Vladimir Dronov Mar 25 '18 at 10:53
  • I'm not an advanced user of DebugDiag but I know that we can customize the output for first chance exceptions. But I haven't seen any setting for second chance exceptions. Simple exception stacks may not be that helpful as they point just the method where the exception occurred. Having really large methods with a multitude of objects involved, it would be difficult to point exactly the corrupted variable. Thanks for your answer @VladimirDronov – Baccarios Mar 26 '18 at 13:28
  • "Having really large methods with a multitude of objects involved, it would be difficult to point exactly the corrupted variable." It's a good idea to have PDB files collected during your build process. If you have .PDB for you .NET code, you will see references to source line numbers in stacks. It can help dealing with big method more efficiently. – Vladimir Dronov Apr 10 '18 at 08:22
  • Here is an example of stack I caught in logfile ' Child SP IP Call Site ... 00000000010fe0d0 00007ffc9e5a2138 NetDebugDemos.SOSBasics.Except() **[C:\Demo\00_Common\src\4.0\SOSBasics.cs @ 230]** ...' – Vladimir Dronov Apr 10 '18 at 08:30
  • The real problem is the huge size of the generated dump files. The Production servers were running out of disk space and/or RAM when generating those dump files. We ended up recreating an environment similar to the Production one trying to reproduce the issue there based on the workflows we suspected to be causing the issue. Not ideal but this is what we could come up with to help the client. Thanks again for your answers @VladimirDronov – Baccarios Apr 11 '18 at 14:02

0 Answers0