Hi,
during some code debugging I found interesting thing I do not understand. Maybe Robert Hook or somebody else can provide some insight?
Using this wiki page I set MicroStation to produce full memory dump including (managed) page heap. It works great, but ... it crashes MicroStation + debugged code at place, where no problem was before (when no full dump with page heap was configured).
I am not author of this part, the only information I was able to obtain is that C# code calls native DLL using DllImport, so I am not able to check whether a bug really exists here.
Instead of it, I checked how the crash monitoring is configured, expected I would be able to understand at least a reason of crash. But I was not able to find explanation for codes used in the reg available on the mentioned wiki page.
For microstation.exe image, it configures:
With regards,
Jan
Hi Jan,
Jan Šlegr said:but ... it crashes MicroStation + debugged code at place, where no problem was before (when no full dump with page heap was configured).
It is best to think of Pageheap (or Bentley's Pagalloc - similar features before pageheap) as "electric fences" for memory allocations. Pageheap can be enabled at an Application (.exe) and/or Module (.dll) level to help ensure a number of pointer related bugs can be caught immediately vs analyzing "later sequenced" resulting damage from a crash (think a train wreck and root cause of it vs. starting to investigate at the back of the wreck first - bad!) .
The other aspect related to debugging is symbols. If you can access all symbols (primarily: .pdb, .dll, .exe) from your own or shared public symbol servers you can quickly reconstruct an exact call stack from the pdb (map file) that will then translate and point you to the exact: Path, Module FileName and LineNumber of any given line in the (stack) available Call Stack. With .NET you need to enable Full Memory Dumps (MS_MINIDUMPTYPE=7 or pageheap's - electric fences); which can slow things down about 33% slower due to the extra memory protection/detection provided. Once a crash is obtained/provided to the appropriate developer then MS_MINIDUMPTYPE=4 or pageheap) then full memory dumps/page heap settings returned back to normal for the user.
The best take-away is to review the exception call stack (windbg - .ecxr;kbn;kPn) and scrutinize the top (3 to 5 typ) lines of the call stack to identify a candidate app module name and line number (or "version thumbprint" + "offset" if you don't have symbols)
Unfortunately Bentley does not provide a public symbol server serving up our private pdb (map files) which limits you to essentially being able to only "debug your own code" (your own local or symbolserver - pdb and binaries). Although full memory and/or pageheap memory dumps are very large you can provide us a copy (Secure Upload) of the crash (possibly with your .pdb files for highest accuracy) then we can evaluate and determine a point of fault in our code, or at the line of code you may already have been able to obtain when opening up and examining the crash dump in Visual Studio or Windbg during the crash dump analysis stage.
This Microsoft article (bottom of your link referenced) helps explain some of the magic numbers and settings (Left hand topics) when you need to Enable page heap - Windows drivers | Microsoft Docs. I try to keep all what I consider to be the best "top level" entry points to learning/exploring related to Debug Microsoft Apps in this wiki.
Let me know if you can do a secure upload and/or if you can provide some more crash information so I can help shine a flashlight on the next area of the problem in need of attention.
HTH,Bob
Answer Verified By: Jan Šlegr
Hi Bob,
thanks for you detail answer.
The main reason for my question was that when MS_MINIDUMP=7 is defined, the application crashed, but everything is fine (or maybe it only looks like that ;-) when no full memory dump with pageheap is requested.
I was curious whether it can be that this mode is intrusive and corrupts something, so the application crashes, especially because WinDbg presents it as AccessViolationException. And, what from the settings, stored in registry, can cause it (regardless it the bug or caused by the minidump mode).
But, from your answer, and what I was able quickly read in the linked documentation, I think now it's hidden bug in the application, that only have not led to crash yet. As mentioned, when pageheap is active, special care about allocated / accessed memory is applied, so also bugs not causing immediate crashes are detected.
Bentley symbols do not help in this specific case, because it's 3rd party code, when NET code access using DllImport native code. The problem is probably in memory (de)allocation, when native char* is returned to managed code. I reported it to the code authors already.
It's funny, because my original intention was used the complete dump to find why my code crashes (only) on a particular PC I have no access to (so I am not able to debug it). But, with the pageheap used, MicroStation crashes before my dll is run ;-)
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Glad you are seeing the true value of pageheap/pagalloc and Microsoft Symbols that can readily produce true code issues pointing to the exact line(s) of code and condition(s) that caused it to get in that state - so you and your: users, qa and developer; don't need to spend time: encountering, configuring, explaining and hoping the person assigned can follow and reproduce those (buggy) steps and conditions needed.
My own policy is if something does not have symbols, it is not supportable in the field and therefore the responsible/owning developer can attempt to debug the dump file at assembly level or build with symbols next time.
Glad to hear you have a flashlight in your toolkit to find a solid path forward.Bob
Robert Hook said:My own policy is if something does not have symbols, it is not supportable in the field
that's make a sense, but not always can be achieved.
Robert Hook said:Glad you are seeing the true value of pageheap/pagalloc and Microsoft Symbols that can readily produce true code issues pointing to the exact line(s) of code and condition(s) that caused it to get in that state
In addition to analysis provided by WinDbg Preview from full memory dump, often big help for me are RedGate tools, especially NET Reflector. Even just as a standalone tool it's great to check how specific assembly is implemented (can replace missing documentation ;-), but great is it's integration with Visual Studio debugger, allowing to debug 3rd party assemblies (because decompiled from IL at background). Nearly always it provides enough information to identify a place and reasons why and where the malfunction happens.
Of course, in the case of native code, symbol files are the only way.
Regards,