I want to programmatically download symbols from the micrsoft symbol server (http://msdl.microsoft.com/download/symbols).
E.g. given the name "ntdll.dll" I want to save the .pdb into any directory.
The APIs from dbghelp.dll seems to solve this. (http://msdn.microsoft.com/en-us/library/windows/desktop/ms679291%28v=vs.85%29.aspx)
But I don't know how to use them in a right way.
Does anyone did something like this before and can show me some example code?
thanks!
I never did something exactly like this, but I was intrigued enough to look. Your friends are the SymXxx functions, within dbghelp.dll.
Start with SymSetOptions followed by SymInitialize.
Then, the function that does the heavy lifting of the work is SymFindFileInPath. The second arguments (SearchPath) is a semicolon-separated search path, that may include SRV*.
The utility that does exactly what you want (pretty much, with nothing less and nothing more) is symchk.exe. Take a look at its imports table, notice it uses no more than 9 functions from dbghelp (and no 'networking' DLL such as winhttp or the like) - so that should give you a good clue how to proceed, and which methods you should use.
Related
I'm using the DIA SDK to get symbol information from .pdb files. For example, I want to use this to get a list of classes, functions, member variables, and so on from a project.
After some messing around I've been able to get this information, however I'm also getting a lot of extra stuff that isn't my own code but is added in after (by the standard library and such).
I've tried filtering this based on the source file of the given symbol, however get_sourceFileName() seems to be unreliable, usually not returning any value.
Any help would be appreciated, whether it's getting get_sourceFileName() to work properly or some other way of filtering out objects from code that isn't part of the project.
Note that I know there are alternatives to the DIA SDK that would make this easier, such as libclang, however those are not an option for this project for various reasons.
The answer to this is not "see the import address table".
I am looking to do some analysis on a few binaries that I am generating, specifically to get a better idea of what libraries and windows API functions I am using. I have used Dependency Walker to take a look at this, but some of the testing I have done indicates to me that there might be a lot of extra function calls put into the IAT, even if they arent called.
What I am looking for is a way to determine what functions are being called... not just what is being put in the IAT.
The best way would probably be to reverse it and look at all of the 'CALL's but I dont know a good way to do that either.
What is the best way to do this?
Launch WinDbg (Debugging tools of windows)
Open the executable you want to analyse.
run the following commands
!logexts.loge
!logexts.logo e v (enables verbose logging)
!logexts.logo e t (enables text logging)
g
Open the logviewer tool come along with debugging tools of windows to see the api's,
Default logs path is desktop\logexts
If you are using link.exe to link your binary, pass /MAP flag at the time of linking.
This will generate a MAP file(binary.map)...it will have functions which are used(not all functions).
I don't know if it's the "best way", but I would kinda agree to your suggestion that all the CALLs give a good overview.
With the "Ollydbg" debugger you can load your program, go the the exe module of your process and rightclick -> search for -> all intermodular calls.
This gives you a nice sortable, searchable list of all "CALL"s that appear in your module and lead to other modules.
I've not done much coding for Windows lately, and I find myself sitting at Visual Studio right now, making a small program for Windows 7 in C++. I need some configuration data to be read/written.
In the old days, (being a Borland kind of guy) I'd just use a TIniFile and keep the .ini beside my exe Obviously this is just not the done thing any more. The MS docs tell me that Get/WritePrivateProfileString are for compatibility only, and I doubt that I'd get away with writing to Program Files these days. Gosh I feel old.
I'd like the resulting file to be easily editable - open in notepad sort of thing, and easily findable. This is a small app, I don't want to have to write a setup screen when I can just edit the config file.
So, what is the modern way of doing this?
Often people use XML files for storing preferences, but they are often overkill (and they aren't actually all that readable for humans).
If your needs would be easily satisfied with an INI file, you may want to use Boost.Program_options using the configuration file parser backend, which actually writes INI-like files without going through deprecated (and slow!) APIs, while exposing a nice C++ interface.
The key thing to get right is where to write such configuration file. The right place is usually a subdirectory (named e.g. as your application) of the user's application data directory; please, please, please, don't harcode its path in your executable, I've seen enough broken apps failing to understand that the user profile may not be in c:\Documents and settings\Username.
Instead, you can retrieve the application data path using the SHGetFolderPath function with CSIDL_APPDATA (or SHGetKnownFolderPath with FOLDERID_RoamingAppData if you don't mind to lose the compatibility with pre-Vista Windows versions, or even just expanding the %APPDATA% environment variable).
In this way, each user will be able to store its preferences and you won't get any security-related errors when writing your preferences.
This is my opinion (which I think most of the answers you get will be opinion), but it seems that the standard way of doing things these days is to store config files like these in C:\Users\<Username>. Moreover, it is generally good to not clutter this directory itself, but to use a subdirectory for the purpose of storing your application's data, such as C:\Users\<Username>\AppData\Roaming\<YourApplicationName>. It might be overkill for a single config file, but that will give you the opportunity to have all of your application data in one place, should you add even more.
My problem is that I'm having trouble specifying paths for Lua to look in.
For example, in my script I have a require("someScript") line that works perfectly (it is able to use functions from someScript when the script is run standalone.
However, when I run my app, the script fails. I believe this is because Lua is looking in a location relative to the application rather than relative to the script.
Hardcoding the entire path down to the drive isn't an option since people can download the game wherever they like so the highest I can go is the root folder for the game.
We have XML files to load in information on objects. In them, when we specify the script the object uses, we only have to do something like Content/Core/Scripts/someScript.lua where Content is in the same directory as Debug and the app is located inside Debug. If I try putting that (the Content/Core...) in Lua's package.path I get errors when I try to run the script standalone.
I'm really stuck, and am not sure how to solve this. Any help is appreciated. Thanks.
P.S. When I print out the default package.path in the app I see syntax like ;.\?.lua
in a sequence like...
;.\?.lua;c:...(long file path)\Debug\?.lua; I assume the ; means the end of the path, but I have no idea what the .\?.lua means. Any Lua file in the directory?
You can customize the way require loads modules by putting your own loader into the package.loaders table. See here:
http://www.lua.org/manual/5.1/manual.html#pdf-package.loaders
If you want to be sure that things are nicely sandboxed, you'll probably want to remove all the default loaders and replace them with one that does exactly what you want and nothing more. (It will probably be somewhat similar to one of the existing ones, so you can use those as a guide.)
I'm using two commercial libraries that are produced by the same vendor, called VendorLibA and VendorLibB. The libraries are distributed as many DLLs that depend on the compiler version (e.g. VC7, VC8). Both libraries depend on a another library, produced by this vendor, called VendorLibUtils and contained in one DLL.
The problem: VendorLibA uses a different version of VendorLibUtils than VendorLibB. The two versions are not binary compatible, and even if they were it would be a bad idea to use the wrong version.
Is there any way I could use the two libraries under the same process?
Note: LoadLibrary can't solve this since my process is not that one that's importing VendorLibUtils.
EDIT: Forgot to mention the obvious, I don't have to source code for any of the commercial libraries and probably I will never have (sigh).
EDIT: The alternative btw, is to do this: How to combine GUI applications in Windows
I think your most promising option is to complain, loudly, to the vendor who is distributing mutually incompatible products. That rather goes against the idea of a DLL.
You can't just put the DLLs in different directories. Once a DLL with a given name is loaded, all other attempts to load another DLL with the same module name will simply use the one that's already loaded, even if the paths are different.
From that, we can conclude that to load two copies of VendorLibUtils, one copy needs to have a different name. You can't just rename the DLL file; the code in your program won't know to look for the different file. Therefore, perhaps there's a way to edit the import table of VendorLibB to make it think the functions it needs are in VendorLibUtilsB.dll instead of just VendorLibUtils.dll. I'm afraid I don't know of any utility that will do that, but I have little doubt it's possible to do.
I had a similar problem. Specifically I wanted to use a PyQt from a Python interpreter embedded in an application that was using an incompatible version of Qt. There were two Qt DLLs used by the primary application: QtCore.dll and QtGui.dll.
When I would load PyQt from the embedded Python interpreter, I would get an error:
ImportError: DLL load failed: The specified procedure could not be found.
This occured on the line:
from PyQt4 import QtGui
The problem is that the once an incompatible QtGui.dll is loaded into the main application's process space any references to QtGui.dll (e.g. from the file QtGui.pyd) are incorrect.
What happened next, I am not proud of.
First I renamed QtGui4.dll in the PyQt distribution to QtGuiX.dll
and then renamed the QtCore4.dll to QtCoreX.dll. Notice that the
renaming maintained the same number of characters, this is important.
Next I opened the file QtGui.pyd in Notepad++, and replaced all
plain-text references of QtGui4.dll to QtGuiX.dll and from
QtCore4.dll to QtCoreX.dll. I repeated the process for the files:
QtCore.pyd, QtGuiX.dll and QtCoreX.dll.
Finally I checked that my PyQt test application still worked. It did!
Then I tried running the PyQt test application from the embedded
Python interpreter, and it worked as well.
So, it seems to works in a couple of trivial cases. I expect that I
need to repeat the process for all DLLs and PYDs in the PyQt
distribution.
This is probably not the right way to do things, but I can't think of any concrete reasons how it could blow up (other than if I change the length of the file name).
Credit (or blame) to others on the thread for inspiring this terrible tale.
As someone else mentioned, you could rename one of the copies of VendorLibUtils and modify the import table of the associated VendorLib DLL to link to it, rather than the VendorLibUtils.dll it was created with.
There's a few tools out there that let you edit EXE/DLL files in this way. CFF Explorer is a pretty decent one which allows editing of the import table. If you open up the VendorLib DLL in it and go to the Import Directory section (in the tree on the left), you'll see a list of modules at the top of the main window. You can rename the module by double-clicking on its name. Then you just save the DLL and it should now use your renamed VendorLibUtils DLL.
Of course, this assumes that VendorLib uses the import table to access VendorLibUtils, which it may not -- it may use LoadLibrary/GetProcAddress, in which case you won't see an import table entry for VendorLibUtils.
Actually, if the VendorLib does use the import table but also uses LoadLibrary to access the VendorLibUtils DLL in some places (I've seen it done), those places will still use the wrong one. If you rename both libraries, you might at least see an error if this is the case (since a DLL with the original name won't exist now). There is a way to deal with this if it occurs, but it starts to get quite complicated at this point, so I won't elaborate unless you really want/need to know.
As you are not using VendorLibUtils directly, I assume you can't use LoadLibrary etc.
If the VendorLibUtils DLLs only have exports by ordinal, you could probably rename one of the the libraries and patch the corresponding VendorLibX to use a different filename for its imports.
If the VendorLibUtils DLLs have one or more exported symbols with the same names, you might need to patch the imports and export tables too, but let's hope not! :-)
I'm no expert in DLLs, but the only way I see it possible would be to use LoadLibrary() and explicitly load the DLLs. Then you could place the functions/classes etc in separate namespaces using GetProcAddress().
HMODULE v1 = LoadLibrary(_T("libv1_0.dll"));
libv1_0::fun_in_lib = reinterpret_cast<FUNTYPE>(GetProcAddress(v1, _T("fun_in_lib"));
and
HMODULE v2 = LoadLibrary(_T("libv2_0.dll"));
libv2_0::fun_in_lib = reinterpret_cast<FUNTYPE>(GetProcAddress(v2, _T("fun_in_lib"));
Whether this would work or not still kind of depends on the library, so it may or may not work, but as far as I can tell it's the only possibility.
You mean, you have a situation similar to MSVCRT80.DLL and MSVCRT90.DLL ? There is a good reason Microsoft numbered these DLLs.If both were called MSVCRT.DLL, only one of them would be loaded in a single process.
It is actually possible to implicitly load different versions of a dll into a single process.
Doing this entails:
Creating two assemblies, each containing a version of the dll that must be loaded multiple times. Sounds complicated but practically it entails little more than creating (2) named sub folders, each with a .manifest file containing some xml, and its own copy of the dll. So, VendorUtilsAssemblyV1 and VendorUtilsAssemblyV2
Making each dependent dll use the assembly mechanism to resolve the implicit dependency - by adding a assemblyDependency directive that explicitly identifies VendorUtilsAssemblyV1 or V2.
There are some options for point 2. If the VendorLibA and VendorLibB files do not contain their own manifests, then you can simply add manifest files with the required dependentAssembly directive named VendorLibA.2.dll.manifest and VendorLibB.2.dll.manifest.
If they already contain manifests (probably to link to the VS2005 or VS2008 C-Runtime) then use the MT.EXE tool to merge in the new dependency.