can someone help me with this error!
"The PROGRAM CANT START because OPENGL.DLL is missing from your system."
I already put the h. and .dll files in the specific directories. i'm working on a 64 bit window 7. microsoft visual c++.
Most systems already have OPENGL.DLL in the Windows System directory.
The way to diagnose this error is to run Dependency Walker (download here).
Run it and open up your .EXE file - and it will tell you specifically what DLL it can't locate, or which is loaded but is not compatible.
OPENGL.DLL
You are sure about that name. Wasn't it opengl32.dll?
I already put the h. and .dll files in the specific directories
Never(!) do this with opengl32.dll. This is a system DLL and must not be overridden by shipping one own's with the program. If you do this, you may very likely end up with not getting HW acceleration.
I had a similar issue and discovered that I had deleted the following line before pasting the test code:
#include "stdafx.h"
Make sure you have the line as above before pasting the test code.
Maybe you could go to one of your friends , and copy this .dll file from his system dictionary
Related
I've been getting in to reverse engineering a bit and have come across a piece of software that I'm unsure how to start on. The software is launched by a batch file (which also calls a second batch file) before it calls the executable. If I load the batch file in to x64dbg I get a PE file error which is expected. But I can't run the executable directly as I get a missing dll error. Any idea how I might get around this to get started? Cheers.
I ended up using Ollydbg instead as it seems to load batch files.
For future references, you can copy the dll(s) to the directory the PE is in. Not sure what software this is, but the downside I can see is possibly running into dependency hell? You won't really know until your executable stops complaining about missing dll's.
So I have been trying to build an installer for my game with NSIS. For the most part it works fine but just noticed that it seems to be skipping certain files for no reason. Or no reason I can figure out.
At first I was using this line to gather up all the files in the source folder:
File /r "${NSISDIR}\game\source\*.*"
However, I noticed that this didn't get everything. Granted it found all sub-folders and kept the hierarchy correct. There didn't seem to be any rhyme or reason to what it skipped. Then I tried listing all files and directories separately and found out why. Example:
File "${NSISDIR}\OWTD-DE\source\pygame.math.pyd"
This produces the following error:
File: "C:\Program Files (x86)\NSIS\game\source\pygame.math.pyd" -> no files found.
But that file exists, I can see it in the source folder. This was the case for all missing files. At first I thought it may be the two periods in the name, but various files have that naming convention and they are added fine. I cannot figure out how to get it to recognize these files. Any ideas?
${NSISDIR} is a define used to access the UI resources in the Contrib subfolder, you are not supposed to put your files there. Your source files should not be in Program Files, only installed files should be located there. Also, on 64-bit systems there are two Program Files folders and there are some compatibility hacks in Windows related to %ProgramFiles% so putting your source files there is not optimal. Just because you see that file there does not mean it is actually in Program Files, it could be UAC Virtualization/VirtualStore tricking you...
Normally you would keep your .nsi somewhere in the same directory tree as the rest of your files so you can use relative paths but you can also use a define if you really want to:
!define MYSOURCE "c:\foo\bar"
...
Section
File /r "${MYSOURCE}\*.*"
SectionEnd
If it still misses some files I would suggest trying Process Monitor so you can see the low-level details...
Weirdly enough, this process did not work very well on Windows Home 64-Bit but did on Windows Professional 64-Bit. I'm not sure if this an issue with NSIS itself or what, but nothing was different between the two except the OS. And there really isn't much difference between those two operating systems. However, perhaps some configuration differences between the two was the real issue.
While marked solved, I'm not really sure what the actual issue and solution could be.
I'm debugging test.exe which reads a file "data.txt" that is present in the same directory as that of the exe. The program works fine when run directly. But when being debugged under winDBG, the CreateFile WinAPI in the code fails with err#2 (Unable to find file). I saw a related thread about a similar issue when debugging with VS - there the solution was to place the data file along with the source/headers. That solves the VS issue, but does not help this WinDBG issue.
Has anyone faced this issue before? Please let me know if you are aware of a solution.
If you use relative file paths, then the working directory of your process will affect how they are converted to absolute paths.
When test.exe is launched in Windows Explorer, its working directory is the folder that contains it. In that case the data file in the same folder can be found correctly.
When you use WinDbg to launch test.exe, unless you explicitly set working directory to the one you want, WinDbg will use its own folder. No doubt that leads to the issue you meet.
http://en.wikipedia.org/wiki/Working_directory
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.
As I had feared some of our old VB6 projects are not playing nice with Windows 7. Some of our customers have already upgraded and our one product is returning this error every time you run the executable:
The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll
First thing I tried was creating a .local in the folder so it uses all the DLL and OCX files packaged with the product. That didn't do anything, though I'm not sure if this .local trick still works in Win7.
Tried turning on compatibility for several previous versions of Windows, that had no effect either.
Hopefully someone else has some more suggestions, as my Google-Fu has failed me on this one.
When start prg. A.P.CS5 on screen get pop up window with message: The procedure entry point handler4 common could not be located in the dynamic link library msvcrt.dll.
I solved it this way:
FOR XP:
Search to folder/C:windovs/system32, found icon dwmapi.dll, once found, rename to 1dwmapi.dll (or whatever, just rename it so that you can find it later if you need it for some reason) - problem solved!