I am trying to find a copy of the program chkmatch. The link everyone points to is http://www.debuginfo.com/tools/chkmatch.html, however this site seem to no longer be up. Does anyone know of a mirror or alternate download location or even an alternative program? I am trying to make a PDB and dll match for debugging purposes.
Welcome to the Internet!
There's Wayback Machine website that helps in such situations
https://web.archive.org/web/20210205095232/https://www.debuginfo.com/tools/chkmatch.html
(And I assume you understand that the DLL and the PDB should be built from the same source with the same options, otherwise it is useless and may give misleading information)
Related
I'm currently doing an assignment that demonstrates the use of CVE-2015-0096. It is also known as 'LNK file vulnerabilty'. I tried to look it up and got some info (mainly involving .DLL files).
I'm a Mac user and I have very little knowledge about .DLL files which is why I couldn't completely understand this vulnerability and now I'm having a hard time to explain it in my document. I would really appreciate if someone can explain it to me precisely what it is in a easier way, considering my weak understanding of windows.
See this.
A windows DLL(dynamically linked library) file is equivalent to a linux/mac SO(shared object).
A DLL is a binary file containing libraries.
A LNK file(normal file link) can contain an image preview.
This preview can be a normal image or an image from some specific windows DLLs.
The problem is that the whitelisted of DLLs for that can be bypassed by adding a special header to the LNK file.
Then, the hacker sets the preview to his DLL.
When the preview is loaded, the arbituarry DLL is loaded and you have remote code execution.
My program needs to locate an existing GhostScript install, and run gswin32.exe (or the 64-bit version if installed) with some command-line options to do a silent conversion of PS to PDF. How should I go about this? I see they add some registry settings under HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\9.07, but I only see a LIB path (which has several paths) and a DLL path, nothing for the EXE. I could work backwards from the DLL path, I guess, but not sure if that will be "future proof".
For the type of app GhostScript is, I would assume they would make this part very easy and obvious, since a lot of programs will be doing exactly this. With all of the free "print to PDF" drivers out there, you would think this info would be easy to find, and maybe it is, but I sure can't find it. Hopefully I'm just missing something, because I don't know where to search, or the right keywords to find it on Google.
I'm tempted to use "GSLite", but so far the only places I've found to download this doesn't have any info on how to download the GS source code for the build of GS they are using, and I think that violates the GS license (not making source code available), so for now I'm just thinking I'll have users install GS themselves, and just look for it -- instead of making it a sub-folder under my app or anything like that.
try ftype (which of course may give acrobat or something, but worth a shot)
maybe some windows expert can tell how to acess the alternate apps list you get by right clicking a ps file...
HKEY_LOCAL_MACHINE\SOFTWARE\Artifex\GPL Ghostscript\9.07
After doing a registry search for a few different keywords, I found the above key which contains a (default) string that points to the install directory. I then did a Google search on that registry key and found some links to the GhostScript source code that sets that value, so I think it is safe to use. I would post those links here, but none of them are good sources (one I had to use Google's "from cache" feature, and the other was just a random person posting a snip-it of GS code). I'm sure it is in the official source code download from their website, if anyone else needs to confirm this, possibly a file named nsisinst.nsi, an install script.
my friend has made a really helpful class library which I use all the time. I usually use Reflector to see what his code does.
What I really wanted to do was to step through his code while I'm debugging. So he gave me his .pdb file.
Foo.dll (release configuration, compile)
Foo.pdb
Now, I'm not sure how I can get it to auto break into his code when it throws an exception (his code, at various points, thorws exceptions .. like A first chance exception of type 'System.Web.HttpException' occurred in Foo.dll ...
Can I do this? Do i need to setup something with the Symbol Server settings in Visual Studio ? Do i need to get the dll compiled into Debug Configuration and be passed the .dll and .pdb files? Or (and i'm really afraid of this one) .. do i need to have both the .dll, .pdb AND his source code ...
I also had a look at this previous SO question, but it sorta didn't help (but proof I've tried to search before asking a question).
Can someone help me please?
Yes you can, if your friend indexes those PDB's, so that the debugger knows where to find the appropriate source in a source-control system, and if your friend uploads those pdb's to a symbol-server, you can perfectly step through the code while debugging.
I have done this for some projects at work, and this works like a charm.
More info about setting up a symbol server:
Source server helps you kill bugs
Setting up a symbol server
Using symstore
The answer is in in the linked question, though perhaps it's not blindingly obvious, so I'll say it: yes, you need to have the source code in order to step through the source code. The PDB file only tells the debugger what line of what source file corresponds to a particular machine instruction.
You don't need to set up a "symbol server" or anything like that. Just get him to send you the source. When you load the PDB file Visual Studio will prompt for the location of the source files if they're not at the same path.
I guess you posted link to another question just to prove that you have searched because that question does have an answer to your question.
I´ve tweaked the VC++ settings so that all of my actual code will go to one place, while compiler generated binaries will go to another. This ncb file is the exception though. It is a quite large IDE generated binary file (Intellisense database). I can´t seem to be able to move it anywhere other than the solution folder. I´ve reasearched on google and found a few references saying that this is impossible. Does anyone have a workaround?
Visual Studio doesn't allow you to move that file. This article on CodeProject shows how one person worked around this problem, by creating a "poor man's" version of symbolic links. This involves hooking Windows' CreateFile function. This approach seems like overkill to me; I think I would just learn to live with this limitation if possible.
Are there any VC++ settings I should know about to generate better PDB files that contain more information?
I have a crash dump analysis system in place based on the project crashrpt.
Also, my production build server has the source code installed on the D:\, but my development machine has the source code on the C:\. I entered the source path in the VC++ settings, but when looking through the call stack of a crash, it doesn't automatically jump to my source code. I believe if I had my dev machine's source code on the D:\ it would work.
"Are there any VC++ settings I should know about"
Make sure you turn off Frame pointer ommision. Larry osterman's blog has the historical details about fpo and the issues it causes with debugging.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code.
What version of VS are you using? (Or are you using Windbg?) ... in VS it should defintely prompt for source the first time if it doesn't find the location. However it also keeps a list of source that was 'not found' so it doesn't ask you for it every time. Sometimes the don't look list is a pain ... to get the prompt back up you need to go to solution explorer/solution node/properties/debug properties and edit the file list in the lower pane.
Finally you might be using 'stripped symbols'. These are pdb files generated to provide debug info for walking the callstack past FPO, but with source locations stripped out (along with other data). The public symbols for windows OS components are stripped pdbs. For your own code these simply cause pain and are not worth it unless you are providing your pdbs to externals. How would you have one of these horrible stripped pdbs? You might have them if you use "binplace" with the -a command.
Good luck! A proper mini dump story is a godsend for production debugging.
If your build directly from your sourcecode management system, you should annotate your pdb files with the file origins. This allows you to automatically fetch the exact source files while debugging. (This is the same proces as used for retrieving the .Net framework sourcecode).
See http://msdn.microsoft.com/en-us/magazine/cc163563.aspx for more information. If you use subversion as your SCM you can check out the SourceServerSharp project.
You could trying using the MS-DOS subst command to assign your source code directory to the D: drive.
This is the procedure I used after some trouble similar to yours:
a) Copied to the production server all the EXE & DLL files that were built, each with its corresponding PDB to the same directory, started the system, and waited for the crash to happen.
b) Copied back all the EXE, DLL & PDB files to the development machine (to a temporary folder) along with the minidump (in the same folder). Used Visual Studio to load the minidump from that folder.
Since VS found the source files where they were originally compiled, it was always able to identify them and load them correctly. As with you, in the production machine the drive used was not C:, but in the development machine it was.
Two more tips:
One thing I did often was to copy an EXE/DLL rebuilt and forget to copy the new PDB. This ruined the debug cycle, VS would not be able to show me the call stack.
Sometimes, I got a call stack that didn't make sense in VS. After some headache, I discovered that windbg would always show me the correct stack, but VS often wouldn't. Don't know why.
In case anyone is interested, a co-worker replied to this question to me via email:
Artem wrote:
There is a flag to MiniDumpWriteDump()
that can do better crash dumps that
will allow seeing full program state,
with all global variables, etc. As for
call stacks, I doubt they can be
better because of optimizations...
unless you turn (maybe some)
optimizations off.
Also, I think disabling inline
functions and whole program
optimization will help quite a lot.
In fact, there are many dump types,
maybe you could choose one small
enough but still having more info
http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx
Those types won't help with call stack
though, they only affect the amount of
variables you'll be able to see.
I noticed some of those dump types
aren't supported in dbghelp.dll
version 5.1 that we use. We could
update it to the newest, 6.9 version
though, I've just checked the EULA for
MS Debugging Tools -- the newest
dbghelp.dll is still ok to
redistribute.
Is Visual Studio prompting you for the path to the source file? If it isn't then it doesn't think it has symbols for the callstack. Setting the source path should work without having to map the exact original location.
You can tell if symbols are loaded by looking at the 'modules' window in Visual Studio.
Assuming you are building a PDB then I don't think there are any options that control the amount of information in the PDB directly. You can change the type of optimizations performed by the compiler to improve debuggabilty, but this will cost performance -- as your co-worker points out, disabling inline will help make things more obvious in the crash file, but will cost at runtime.
Depending on the nature of your application I would recommend working with full dump files if you can, they are bigger, but give you all the information about the process ... and how often does it crash anyway :)
Is Visual Studio prompting you for the
path to the source file?
No.
If it isn't then it doesn't think it has symbols
for the callstack. Setting the source
path should work without having to map
the exact original location.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code. I can of course search in files for the line in question, but this is hard work :)