The application which I am debugging crash dumps from the customer has various release cycles. So the PDBs are not maintained for all the releases. whenever we get a crashdump from customers the PDB files are not available. Due to this, it's difficult to analyze crash dumps. I use Windbg to analyze the crash dumps. Windbg has the option to forcefully use unmatched PDBs. But with using this option the analysis is not giving right call stacks. So is there any other way through which Crashdumps can be analyzed without having a dependency on PDB files? This is required to resolve my current problem. Or how windbg can be used without having a dependency on PDB files.
TL;DR: if you delete the PDBs, don't complain. Disk space is cheap. A 1 TB hard disk is at 40 €. If PDBs save you an hour of work, it's worth buying one. Turn on NTFS compression, because PDBs compress quite well.
whenever we get a crashdump from customers the PDB files are not available
Obviously, that's the wrong strategy. You can throw away PDBs from nighly builds, but not of releases that go to customers.
Due to this, it's difficult to analyze crash dumps.
Yes, that's true. So why make your life extra hard? Keep the PDBs.
Windbg has the option to forcefully use unmatched PDBs. But with using this option the analysis is not giving right call stacks.
Yes, because that's the purpose of correct PDBs.
So is there any other way through which Crashdumps can be analyzed without having a dependency on PDB files?
Yes, you can do it without PDBs. But, as you said, it's extra hard.
Or how windbg can be used without having a dependency on PDB files.
Again, debugging is possible without PDBs. Maybe you might to learn assembler code.