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
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.
I'm using SDL in VS2013 and I'm trying to load an image from the folder that my working directory should be using a relative path. Which is where the .vcxproj files are. However I discovered that the working directory is not the folder it should be, it is actually in C:\Windows\System32. I have realised that this is only the case when I go to linker, system and then change the subsystem to CONSOLE. In a WINDOWS subsystem it uses the correct working directory. Why is this happening and how do I fix it?
I think it may have something to do with VS2013 using cmd.exe which is in the system32 folder but I cannot be certain and would not know how to fix it even if that is the case.
Hmm...I don't think I've ever had that problem, and I always write with the console window. Have you tried just making a new project to see if maybe something got set in your properties by accident or something? I would give that a try, or maybe re-install SDL..? That's weird, sorry I don't have better advice!
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
I have a Windows service application on Vista SP1 and I've found that users are renaming its executable file (while it's running) and then rebooting, thus causing it to fail to start on next bootup because the service manager can no longer find the exe file since it's been renamed.
I seem to recall that with older versions of Windows you couldn't do this because the OS placed a lock on the file. Even with Vista SP1 I still cannot copy over the existing file when it's running - Windows reports that the file is in use - makes sense. So why should I be allowed to rename it? What happens if Windows needs to page in a new code page from the exe but the file has been renamed since it was started? I ran Process Monitor while renaming the exe file, etc, but Process Mon didn't report anything strange and just logged changing the filename like any other file.
Does anyone know what's going on here behind the scenes? It's seem counter intuitive that Windows would allow a running process' filename (or its dependent DLLs) to be changed. What am I missing here?
your concept is wrong ... the filename is not the center of the file-io universe ... the handle to the open file is. the file is not moved to a different section of disk when you rename it, it's still in the same place and the part of the disk the internal data structure for the open file is still pointing to the same place. bottom line is that your observations are correct. you can rename a running program without causing problems. you can create a new file with the same name as the running program once you've renamed it. this is actually useful behavior if you want to update software while the software is running.
As long as the file is still there, Windows can still read from it - it's the underlying file that matters, not its name.
I can happily rename running executables on my XP machine.
The OS keeps an open handle to the .exe file,. Renaming the file simply changes some filesystem metadata about the file, without invalidating open handles. So when the OS goes to page in more code, it just uses the file handle it already has open.
Replacing the file (writing over its contents) is another matter entirely, and I'm guessing the OS opens with the FILE_SHARE_WRITE flag unset, so no other processes can write to the .exe file.
Might be a stupid question but, why do users have access to rename the file if they are not suppose to rename the file? But yeah, it's allowed because, as the good answers point out, the open handle to the file isn't lost until the application exits. And there are some uses for it as well, even though I'm not convinced updating an application by renaming its file is a good practice.
You might consider having your service listen to changes to the directory that your service is installed in. If it detects a rename, then it could rename itself back to what it's supposed to be.
There are two aspects to the notion of file here:
The data on the disk - that's the actual file.
The file-name (could be several or none) which you can give that data - called directory entries.
What you are renaming is the directory entry, which still references the same data. Windows doesn't care about your doing so, as it still can access the data when it needs to. The running process is mapped to the data, not the name.
Basically what I want to do it this: a pdb file contains a location of source files (e.g. C:\dev\proj1\helloworld.cs). Is it possible to modify that pdb file so that it contains a different location (e.g. \more\differenter\location\proj1\helloworld.cs)?
You can use the source indexing feature of the Debugging Tools for Windows, which will save references to the appropriate revisions of the files in your source repository as an alternate stream in the PDB file.
If you're looking to be more generic about the paths embedded in a pdb file, you could first use the MS-DOS subst command to map a particular folder to a drive letter.
subst N: <MyRealPath>
Then open your project relative to the N: drive and rebuild it. Your PDB files will reference the source files on N:. Now it doesn't matter where you place that particular set of source files, so long as you subsequently call the root directory "N:" like you did when you built it.
This practice is recommended by John Robbins in his excellent book, Debugging Applications for Microsoft .NET and Microsoft Windows.
I wanted to find the answer to this in order to debug a crash dump that occurred in an executable that I did not build on my machine, therefore the path to the source code referenced in the PDB was invalid, as was the path to the PDB referenced in the executable.
After searching around and failing to find something that works, I discovered that if you place the executable and PDB alongside the crash dump file (i.e. in the same directory) then open and run the crash dump in VS, VS will find and use the PDB/EXE locally. Furthermore, it will also prompt for the location of the source code when clicking on an entry in the call stack: pointing it at whichever source code is relevant, it all works fine, which is great!
Anyway, hopefully this helps someone else...:)
It is certainly possible, as On Freund has already pointed out.
But if it is only so that the sources can be located and loaded during debugging, then a better way would be to set the source path correspondingly. Once set in a debugger, it will preemt all hard coded paths inside PDBs.
In windbg (for instance):
.srcpath+ path_to_source_root
or this (in case you're debugging remotely):
.lsrcpath+ path_to_source_root