Code:Blocks uses gdb too. So same result is to be expected. (on the same executable)
If I understand the external post (go) correctly, then without the check you are highly likely to get wrong frames in the trace. That would not be much more helpful?
I do not know all the tricks that gdb may (or may not) use to get a trace.
A normal stack follows certain rules, involving 2 registers SP (esp or rsp) and BP (ebp or rbp). So long as all the code uses them correctly, the stack should be ok.
With one exception already: If you are on the very first line, or the very last line (in most cases a handful of asm statements) then it may not work (it also may work), because the asm is just building the frames for the stack. Those parts of code a called prologue and epilogue.
In addition to that a compiler can write dwarf info helping the debugger. I do not know if fpc does, or if gdb uses this (if coming from fpc).
But since the issue is with code in the kernel or 3rd party lib, it would not help
Further more maybe (no idea) gdb reads the surrounding asm, and tries to make guesses what to expect.
IF so, then in that case gdb would best know asm as generated by gcc.
Now as for the correct usage of those 2 registers.
On certain optimization levels, and under very restrictive conditions fpc itself omits this. (for speed).
The rtl as compiled in the installer, has a few such cases.
Those cases always lead to the next higher frame being hidden. That is: one frame from the stack is simply not shown.
I have never bothered to check, but it is plausible that the kernel (and 3rd party libs) also omit this.
If they do that would also lead to skipped frames.
But combined with other optimizations, this can lead to the stack being entirely unreadable.
The stack contains a mixture of local vars, temp data, and the address of calling functions.
Only if you know, where in this mix the address of the calling function is, can you read the next frame.
It is possible that sysinternal (being specific to Windows) has access to further debug info of the kernel. If such info exist, it would be in a windows specific format (and not dwarf) or even hard-coded into sysinternal products. GDB can only read dwarf (and stabs).
Anyway there is nothing that can be done. (you can report with gdb, but that is a long shot)
Recent
