I met a problem when building with Visual studio, it says one DLL is not accessible because it is currently used by another process, my question is how can I determine the "another process"?
Process Explorer has a facility that allows you to search through the currently running processes for a specific file. To perform this search go to Find->Find Handle or DLL... and then enter the name of the file you are interested in.
tasklist /m thelocked.dll
Suggested by
https://blogs.msdn.microsoft.com/winclient/2004/07/08/how-to-find-out-which-process-is-locking-a-dll/
While Process Explorer is the best tool in general, what this error usually means when VS throws it at you is that the application you're trying to compile is still running (from an earlier run) and therefore the linker can't write its output.
Also you may use "close handle" feature inside Process Explorer.
Use the Find function (Find -> Find Handle or DLL) from SysInternals Process Explorer.
I would suggest you try unlocker. Helped me quite a few times.
You can use Process Explorer to see what processes have loaded which Dll's.
Related
I've researched it all over StackOverflow and Google but only get results about C# and irrelevant topics, so now I have to ask. I want after 20 seconds of the application being open to close itself and open another application that is in the same folder. After I have debugged, I copy the application to the folder on my Desktop that I will eventually ZIP up. But I want the app to open another application in the folder. Say for instance ApplicationA.exe Opens and after 20 seconds it closes and ApplicationB.exe opens.
You can use the CreateProcess() winapi function which acts like fork()+exec() and then exit() the ApplicationA. Also you can use Sleep(miliseconds) for the delay.
Here is the information about CreateProcess():
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
You can open it with system("ApplicationB.exe"); and then exit. This will start ApplicationB.exe and exit ApplicationA.exe.
Check out: http://www.dreamincode.net/forums/topic/18057-run-external-executable/
I believe C++ is not really the best way to go for system calls like the ones you need to do here. Maybe shell scripting would be a better option.
Anyway, the easiest way is probably writing a third program that opens ApplicationA.exe, closes it and starts ApplicaionB.exe.
I believe in C++ you'd have to use system, which you find in <cstdlib>. Yes, it is a C feature, not a C++ one, and its use is not encouraged, to put it mildly.
I would recommend using the ShellExecute function. http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx
after I compiled my project in C++ (VisualStudio) around 3-4 times, I can do it anymore due to LNK1168 that stands for "VisualStudio can't write into the exe". I've looked up in my TaskManager, the exe is NOT running. Normally I have to wait for like 5 minutes but that isn't a real solution. Any ideas?
ProcessExplorer just tells me, that the handle is invalid and though can't be closed. It remains open all the time...
First thing that comes to mind is to use ProcessExplorer to figure out what process is keeping the file open. Download and start up the tool en select Find from the menu. Enter the (partial) file name and it should show up in the search results. Double click to jump to the process and file handle in the main application window.
I'm guessing Visual Studio is the culprit.
Fortunately, you can also use Process Explorer to close the handle. Right-click and choose Close Handle.
Note that it's not a good idea to go around closing file handles on a regular basis. However, whenever you're in a pickle it can really help solve annoying problems.
If I recall correctly, a similar problem existed way back in VS 6. It had to do with incremental compilation. For a more structural solution, try doing a full rebuild from time to time or disabling incremental compilation all together.
I have been experiencing exactly the same problem (For C# and C++). I have just discovered that having the Application Experience Service disabled seems to cause EXPLORER.EXE To keep .exe files hanging around (locked by the SYSTEM) for several minutes after running that executable.
The solution to this problem, for me at least, was to re-enable the Application Experience service. (I had originally disabled it since it seemed unnecessary - Apparently I was wrong!)
Your exe might still be running. Stop it before recompiling it.
I can't be clearer than my title. :P
I want to run my program whenever a user renames a file in Windows Explorer (and only within the Explorer). Here's a simple mock up:
A simple link to a tutorial will be very helpful. I couldn't find anything. :/
Thank you in advance.
P.S. I'm new in C++
It looks like Windows API hooking may be your best bet. You'll want to intercept all calls related to Windows file renaming (i.e. MoveFile, MoveFileEx, SHFileOperation, possibly more). There are a few commercial and open source solutions; Microsoft Detours, Madshi's madCodeHook, and the free, open source EasyHook.
This approach, when done correctly, will allow you to capture all file renaming on a system.
I would avoid hooking APIs as much as possible. It gets really ugly really fast.
There are 2 ways I see that you can approach this.
Both ways have a few common factors:
The ReadDirectoryChangesW API. For a very good implementation of that API, see this
article
You will need to minimize your dependencies, so... Use a Microsoft compiler, link to the DLL runtime, stick to C as much as possible etc. This reduces problems. Loading things into the shell memory space is already problematic enough.
Method one is to use ReadDirectoryChangesW from an Explorer shell extension that does nothing else. Keep it minimal. I'm reasonably sure I saw a "do nothing" shell extension as an example in some of Microsoft's documentation.
Method two would be to package your code as a DLL and use a system hook to get your DLL loaded into Explorer only. The system hook should only load inside Explorer to prevent spurious notifications via ReadDirectoryChangesW.
Hope this helps and that you're not using it for something Evil.
What Windows API functions are available to execute command prompt's functionality? For example, I like to execute dir command and want to show the output in GUI without using cmd.exe in Windows.
You can start cmd /c dir S:\ome\Path from your process and grab the output. Otherwise it's not possible. But if you're not interested in particular formatting details of dir then you're probably better off just enumerating files/directories and display them.
The dir command is built into the cmd.exe, it's not a separate executable. There's no way of executing it short of running cmd.exe.
EDIT: As for the displaying of results, you need to fill in the STARTUPINFO.hStdXXX members, probably using an anonymous pipe. See this example.
For a console app you can use popen(), but things are by no means so easy from a GUI app. See http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx for one approach.
If you want a listing of files in a given folder see this question which describes how to achieve it, using windows api or a more generic boost approach.
Everything the Windows command line does is done through the Win32 APIs.
For example, with regard to "dir", FindFirstFile() and FindNextFile() will give you the contents of a directory.
For any given command, you will need to figure out which APIs/function calls are in use and then learn how to use them yourself in your own code.
If my C++ app crashes on Windows I want to send useful debugging information to our server.
On Linux I would use the GNU backtrace() function - is there an equivalent for Windows?
Is there a way to extract useful debugging information after a program has crashed? Or only from within the process?
(Advice along the lines of "test you app so it doesn't crash" is not helpful! - all non-trivial programs will have bugs)
The function Stackwalk64 can be used to snap a stack trace on Windows.
If you intend to use this function, you should be sure to compile your code with FPO disabled - without symbols, StackWalk64 won't be able to properly walk FPO'd frames.
You can get some code running in process at the time of the crash via a top-level __try/__except block by calling SetUnhandledExceptionFilter. This is a bit unreliable since it requires you to have code running inside a crashed process.
Alternatively, you can just the built-in Windows Error Reporting to collect crash data. This is more reliable, since it doesn't require you to add code running inside the compromised, crashed process. The only cost is to get a code-signing certificate, since you must submit a signed binary to the service. https://sysdev.microsoft.com/en-US/Hardware/signup/ has more details.
You can use the Windows API call MiniDumpWriteDump if you wish to roll your own code. Both Windows XP and Vist automate this process and you can sign up at https://winqual.microsoft.com to gain access to the error reports.
Also check out http://kb.mozillazine.org/Breakpad and http://www.codeproject.com/KB/debug/crash_report.aspx for other solutions.
This website provides quite a detailed overview of stack retrieval on Win32 after a C++ exception:
http://www.eptacom.net/pubblicazioni/pub_eng/except.html
Of course, this will only work from within the process, so if the process gets terminated or crashes to the point where it terminates before that code is run, it won't work.
Generate a minidump file. You can then load it up in windbg or Visual Studio and inspect the entire stack where the crash occurred.
Here's a good place to start reading.
Its quite simple to dump the current stackframe addresses into a log file. All you have to do is get such a function called on program faults (i.e. a interrupt handler in Windows) or asserts. This can be done at released versions as well. The log file then can be matched with a map file resulting in a call stack with function names.
I published a article about this some years ago.
See http://www.ddj.com/architect/185300443
Let me describe how I handle crashes in my C++/WTL application.
First, in the main function, I call _set_se_translator, and pass in a function that will throw a C++ exception instead of using structured windows exceptions. This function gets an error code, for which you can get a Windows error message via FormatMessage, and a PEXCEPTION_POINTERS argument, which you can use to write a minidump (code here). You can also check the exception code for certain "meltdown" errors that you should just bail from, like EXCEPTION_NONCONTINUABLE_EXCEPTION or EXCEPTION_STACK_OVERFLOW :) (If it's recoverable, I prompt the user to email me this minidump file.)
The minidump file itself can be opened in Visual Studio like a normal project, and providing you've created a .pdb file for your executable, you can run the project and it'll jump to the exact location of the crash, together with the call stack and registers, which can be examined from the debugger.
If you want to grab a callstack (plus other good info) for a runtime crash, on a release build even on site, then you need to set up Dr Watson (run DrWtsn32.exe). If you check the 'generate crash dumps' option, when an app crashes, it'll write a mini dump file to the path specified (called user.dmp).
You can take this, combine it with the symbols you created when you built your server (set this in your compiler/linker to generate pdb files - keep these safe at home, you use them to match the dump so they can work out the source where the crash occurred)
Get yourself windbg, open it and use the menu option to 'load crash dump'. Once it's loaded everything you can type '~#kp' to get a callstack for every thread (or click the button at the top for the current thread).
There's good articles to know how to do this all over the web, This one is my favourite, and you'll want to read this to get an understanding of how to helpyourself manage the symbols really easily.
You will have to set up a dump generation framework in your application, here is how you may do it.
You may then upload the dump file to the server for further analysis using dump analyzers like windbg.
You may want to use adplus to capture the crash callstack.
You can download and install Debugging tools for Windows.
Usage of adplus is mentioned here:
Adplus usage
This creates the complete crash or hang dump. Once you have the dump, Windbg comes to the rescue. Map the correct pdbs and symbols and you are all set to analyze the dump. To start with use the command "!analyze -v"