Is there a detailed specification of the minidump format used by google's breakpad tools? I need to create a minidump file based on a processor/os not currently supported by the breakpad client libraries, and I haven't yet found any concise documentation that describes the actual format of the minidump file itself.
This is an embedded system, and I don't have much to put in the dump file, mainly stack trace and status codes.
The breakpad client sources for existing platforms build the minidump writer into the exception handler, using system calls to gather the information. In my case I am not running the dumper in the exception handler so I am capturing the critical information and need to write the dump file later.
A pointer to a good explanation of the minidump format used by breakpad would be a big help.
I believe what you are looking for is the Windows minidump format. The documentation for Breakpad states:
The Breakpad processor can handle dumps in the minidump format, either
generated by a Breakpad client “handler” implementation, or by
another implementation that produces dumps in this format. The
DbgHelp.dll!MiniDumpWriteDump function on Windows produces dumps in
this format, and is the basis for the Breakpad handler implementation
on that platform.
...
The minidump format is essentially a simple container format,
organized as a series of streams.
...
The minidump format was chosen as Breakpad’s dump format because
it has an established track record on Windows, and it can be adapted
to meet the needs of theother platforms that Breakpad supports.
Related
I am creating an application in Qt which can be used by users to read some confidential text file. The idea is that if a user wants to access this file, he can only do so through this application and not read it directly. I am planning to add this file using qrc resource.
What I would like to know is that:
Is it possible for a user of the application to somehow "extract" the embedded resource from the compiled executable?
If so, in order to prevent this, is it possible to encrypt or hash the said resource before compiling?
P.S.Maybe someone out there has already faces this scenario and came up with a better solution then what I am thinking. If so, new ideas are always welcome.
Depending on your level of expertise, you could make retrieving the text a bit more difficult, but you won't get a secure result this way.
rcc (Qt's resource compiler) tries to compress a resource and if the resource compresses to less than 30%, it will compress the resource. Otherwise the resource will go uncompressed into your executable. As a starting point, you could persuade rcc to always compress by calling rcc with option -threshold 1.
Next you will have to make sure, that all debug symbols are erased from your delivery, otherwise an astute code reader will do something like this:
objdump -all-headers your.app/Contents/MacOS/your | grep qrc
and will get something like this:
00000001002162f0 l F __TEXT,__text __GLOBAL__sub_I_qrc_resources.cpp
Where 00000001002162f0 is a good starting point for disassembling your executable.
Still: Even if you remove all debug symbols, your resources will always pop up in the DATA section of your code.
So even if you are following this and further advice people might give, it's just obfuscation. Welcome to the wonderful world of cryptology and steganography.
How to convert PDB file to XML file? I tried the source from below, but it's taking exe as an input. Is there any opensource converter available?
The ISymbolReader interface from Microsoft needs a metadata token, which can be retrieved from the assembly using Reflection. I don't know a way to read the PDB on its' own - for my purposes, I always have the pdb and the assembly handy, so it hasn't been an issue for me.
So this is the situation. Our company has its own standard codes and windows (for commonly used routines and for inheriting) that we use in developing applications. These "standard codes and windows" is saved in its own library (pbl). Normally when we deploy our software to the client we just compile it to pbd's and exe's, but this time our client wants also the source code of the software. The thing is we don't want our standard codes and windows to be visible when we give the source code to the client. So is there a way to encrypt (shield, hide etc...) the codes.
I hope someone can point me to where should I start researching.
The .pbls contain sources, resources and binaries, while the .pbd contain no source.
If you do not want to leak any source code, just give the .pbd and .exe files.
If you do want to give the source code of the application minus the source code of your standard library, give the all .pbl files but your standard library, and give the .pbd of the standard lib. Thus your client will even be able to recompile the app (providing that the standard lib object are called by, but do not call other pbjects from the application).
Please note that like Java, the PowerBuilder objects can be decompiled from binaries with the right tool.
I am not aware of a mean to encrypt PB source code, but there is the possibility to obfuscate the objects through PB-Protect. I never used it and I cannot tell more about it.
If they're actually looking for insurance should you disappear, perhaps a code escrow service might be acceptable? My company escrows our source at customer request as a paid-for contract line item, I think with Iron Mountain.
I am trying to trace a possible memory leak in a very large ASP.NET application. I am trying to familiarize myself with WinDBG before attempting to use this tool in the live environment.
I have followed the instructions in the following article, which I found very helpful: http://humblecoder.co.uk/uncategorized/spotting-a-memory-leak-with-windbg-in-net. I am able to create a "memory dump" file of the ASP.NET process and show that the delegate is causing the memory leak as specified in the article. I refer to the paragraph in the article that starts: "Next we need the symbols". I did not add the symbol files using File\Symbol File Path; in WinDBG and yet I still seem to be able to debug the application and follow through the remaining steps of the article. Are symbol paths not required with an ASP.NET application?
Because .NET assemblies contain metadata, including the name of every method and its parameters, symbols aren't necessary to obtain a readable stack trace of a managed thread.
One thing symbols can provide is the file name and line number of each statement, so you can more easily figure out which frames in the stack trace correspond to which lines in your source code.
As Michael says symbols are not strictly necessary for managed code as most of the relevant information is available at runtime as metadata, but if you're digging into native code it is very useful to have symbols.
For many scenarios you can just do .symfix which will tell WinDbg to use Microsoft's public symbol server. That will give you access to symbols for all the CLR and Win32 specific calls in your code. Remember to do a .reload if you set the path.
If your code includes native non-Microsoft assemblies as well, you need to append the location of the corresponding PDB files to the symbol path. Use the .sympath command for that.
To troubleshoot symbol loading use the !sym noisy command.
For more information see this.
When ngen is executed on a .NET managed application at installation time, and a crash dump is retrieved from Windows Error Reporting for the app, how can you use it to see a stack trace, variables, etc.?
Here's some background related to the question: We have a .NET app that gets ngened at installation. When it crashes due to an unhandled .NET exception, the crash is bucketted in Windows Error Reporting, and from that I was able to download the minidump.mdmp file from winqual.microsoft.com.
I put minidump.mdmp in a folder containing the .dbg files for the build of the app that crashed, and double-clicked minidump.mdmp to open it in a new instance of VS2008 SP1. My stack trace looks like this:
kernel32.dll!RaiseException() + 0x3d bytes
mscorwks.dll!RaiseTheExceptionInternalOnly() + 0x295 bytes
mscorwks.dll!JIT_Throw() + 0x130 bytes
MyApp.ni.exe!000007feee74c84c()
[Frames below may be incorrect and/or missing, no symbols loaded for MyApp.ni.exe]
0000000070000d5e()
MyApp.ni.exe!000007feee611000()
000000000300bf78()
000000000300bf60()
The Modules window indicates that symbols are loaded for the OS and .NET DLLs, but for the application modules, I get this:
MyApp.exe -> No native symbols in symbol file.
MyApp.ni.exe -> No matching binary found.
MyAppsLibrary.ni.dll -> No matching binary found.
The easiest way to debug those dumps is with the Windows Debuggers (Windbg, cdb, or ntsd) and to load the SOS debugger extension (you can search for SOS for more details).
As far as I remember, the NGEN'ed part of thing shouldn't matter for SOS as long as you have the original EXE and the symbols (Since it's your app, I'd expect you have the non ngen'ed exe and symbols).
"Debugging Tools for Windows" (specifically, WinDBG) has limited support for managed apps. Provided with PDBs, you should be able to see the call stack, including source line references. To see variable values, you'll need to use the SOS plugin, which is more difficult that just opening the call stack window.
If you're able to request the clients to run your app again, ask them to run it with the following environment variable set: COMPLUS_ZapDisable=1
This way CLR won't load the native images when running your app and you'll see your usual modules with symbols on the stack.
http://referencesource.microsoft.com/faq.aspx
Is this of any help for you:
Symbol issue when debugging C# code
The guy seems to be able to load some symbols to debug his application from the crash dump, had a problem loading the correct symbols but someone answered his question.
Since this is managed code, you may need to set the _NT_EXECUTABLE_IMAGE_PATH environment variable to point to the folders where your executables live. In this case, you'll need to locate the folder in the NativeImage cache that points to your assemblies. The debugger needs the images in order to load the assembly.