I'm a little new to it and I don't understand the threading term completely yet, Allthough I know how to make a thread and run programs with multiple threads. What I'm wondering about is that when you create a dll file (c++) and inject it into a process (lets say gamehacking) for instance. Would you need to create threads in the dll file, or is that not going to work? After my understanding the main thread will be running from the host process right? Or how does it work?
Well it depends on what you are planning to achieve using the DLL. If that particular DLL has some static functions / utility class, that just takes an input, doing some calculations / processing and produce an output, then there is no need of threading here.
But if that DLL is going to listen on a socket or write to a file or do the actual work that going to need some parallelism, then you might want to create threads inside that DLL.
Basically you must need to understand, what is that task, that is accomplished by this DLL. A DLL can be linked during compile time as a normal library or it can be loaded dynamically in run-time based on your need / use-case.
To answer your question,
Would you need to create threads in the dll file, or is that not going to work?
Ans : Not always. You need to create thread to accomplish some task. That being said, this is not the case always. It is perfectly feasible to run a DLL inside a process, without having any threads.
After my understanding the main thread will be running from the host process right? Or how does it work?
Ans : That's right. Any process you run, there will be one thread by default. If your application is simple enough to be processed by a single thread, then it is a blessing. Keep up with it :)
Since you are specifically refering to injecting the DLL, I have some input for you additionally to what has already been said.
First, let's make sure that the concepts of threads, processes and modules are clear.
A thread is basically the immediate environment in which code runs. Things like the current state of processor registers and stack variables (e.g. your local variables in functions, in most cases, but also where in the code the execution currently stands) belong to a thread. There are also other resources which often have thread-affinity, such as windows. It depends a lot on the resource in question whether and what kind of thread affinity they have.
Let's assume you write a simple hello world program. It will run in one thread which goes through your program from the beginning to the end and print "Hello World". Now let's assume you would want to write a program which slowly writes "Hello World", one character per second, but in the meantime download a file. Then you could create a second thread and have one thread output "Hello World" slowly, and one thread download the file. This means execution can happen in parallel, with different local state - one thread is currently inside your printHelloWorld function and one thread is inside downloadFile.
A process is basically a container for one or more threads. It bundles them together in a shared environment which uses the same virtual memory (this means that for example global variables in your code would be accessible from all threads, but this would require careful synchronization to avoid race conditions) and shares resources such as file handles the threads in the process create. So, your hello-world-and-download program from before would have 2 threads in 1 process, sharing the console for example, and being seen in the task manager as one entity.
A module is a file which contains executable code (in most cases, that is) and is loaded into a process. Usually, in a process there are one EXE file and several DLL files loaded as modules. DLL files and EXE files are technically almost the same, but EXE files are meant to be the basis from which a processes starts, and DLL files are meant to be libraries exporting certain functions which can be used by other modules. Since I said modules are loaded into processes, it means that a module is accessible by all threads in the process, and it doesn't have thread-affinity by its own - in our previous example, when the second thread downloads the file, it may be calling into a HTTP-networking DLL, whose code would then run in the second thread. There is a number of modules which is loaded automatically into each process by Windows, and others are probably loaded by certain features of your compiler.
OK, so, back to your question:
Would you need to create threads in the dll file[...]?
Per se, using a DLL has nothing to do with whether you need to create new threads or not. It depends on what you want to do - if you need to do some time-consuming task in parallel to whatever other code is running, then you would need to create a new thread for it, otherwise there is no need.
[...]or is that not going to work?
As said, you can create new threads if you want (it will work), but it's not a necessity coming with using a DLL.
After my understanding the main thread will be running from the host process right?
The main thread of the host process will of course be in the host process. (Although there is technically no "main thread", since it's perfectly valid to have the first thread in a process create a second one and then terminate, so only the second one would be running anymore, you usually do have the first thread live through the whole lifetime of the process, and you can probably call it the "main thread" in this case.) In which module the currently-running code is located, though, will depend on what the thread is currently doing.
Let me get back to the matter of "injecting": The previous answers appear to have assumed a more "normal" environment where your DLL is just linked to the program and meant to be loaded by it. In this case, your DLL's initialization routine (which is automatically run when a module is loaded into a process) would just be run in the "main thread", probably before the actual work of the process begins.
However, things are a bit different when you inject a DLL. It depends on how you do the injection:
If you inject the DLL by modifying the imports table of the host EXE, then your DLL will be loaded the "normal" way I just said. So you can expect your initialization routine to run during the process' startup, in the main thread.
If you inject the DLL by using the AppInit_DLLs registry key, it would be the same.
Same thing if you inject the DLL by starting the host process suspended, then writing a stub to load the DLL into the processes' memory and using SetThreadContext to point the instruction pointer to it.
If you inject the DLL through means of remotely calling LoadLibrary inside the target process, using CreateRemoteThread, then however, as the name suggests, you are creating a new thread inside the process. In this thread, LoadLibrary will load your DLL and also call your initialization routine, so in this case, your initialization routine would indeed run in a new thread other than the "main thread".
Every process has at least one thread. When that process starts, it's possible to link a bunch of functions, or a library, to the memory space of that process. That's what a dll is. The advantage compared to linking directly to the binary is the library only has to exist in one place in the file system and one place in memory while being used by multiple processes. It's a linking technique, similar to how .so files are used in Linux. It has nothing to do with threading.
Would you need to create threads in the dll file, or is that not going to work?
There wouldn't be any point loading a DLL that didn't contain code that would be run. That said, there are several ways the DLL code might get run:
when the DLL is loaded it gets a chance to run some initialisation code
during initialisation, it might:
start one or more threads, which can keep running - perhaps watching for some event that triggers some action on their part
register for callbacks from the OS or application, such as setting up signal handlers, keystroke handlers, any type of event handler....
it might contain functions that the program will look for dynamically and run, mistaking your DLL code for the original versions of those functions that the program came with
Which of these suits your needs depends entirely on what your DLL is trying to achieve, and what's technically necessary to achieve it. For example, if watching for some memory to have specific content, then modifying it further, it might suffice to have a function in your DLL called by an OS alarm service, resetting itself to go off again later if the triggering memory content is not found. But, the trigger might be existence of a file, or shared memory service, a socket being created etc..
After my understanding the main thread will be running from the host process right? Or how does it work?
Yes - threads started within a process - including any DLL initialisation routines - are also within the process. There are some library functions that may create other processes - such as fork, popen, system - that may contain their own threads.
Related
A while back I made a post regarding creating a dll, for the purpose of injection, that will cause the host application to trigger an Nvidia Optimus laptop to "awaken" the dGpu. This being necessary because of the pathetic system nvidia created here which results in MANY applications not recognizing the presence of the power dGpu, and instead using the integrated intel gpu. (Specifically some video processing apps which take hours longer using Intel's than it would Nvidia's). That post was here.
Suffice to say, I moved to work in Antarctica and gave up on the project. I just picked it back up years later and decided to learn (enough) C++ to program it here. I have created the DLL, and if I place the DX code in a function, then call that function from a host "caller" program.. IT WORKS!!! However, if I put that code in the DLLMAIN, and then simply load that dll from my "caller" program (without actually calling a specific function)... the procedure executes!!! However, when it gets to the part of the code where CREATEDEVICE is run, it crashes. I have since learned this is due to an issue called deadlock, or loaderlock.. i'm not sure which. I understand the concept, but don't have anywhere NEAR the C++ understanding to develop a workaround.
So basically.. can I run my procedure in DLLMAIN using some workaround? Maybe spawning an independent thread somehow (so DLLMAIN can finish executing to it's return?) Thanks for any info. I'll include the vcproject source code here.. but it's a Frankenstein of things I found online.. so don't look for elegance- I know next to nothing about C++ programming! http://s000.tinyupload.com/index.php?file_id=07876333208461296171
The loader lock is a lock which is per-process and owned just after you call LoadLibrary, until just before the LoadLibrary returns. It is intended to ensure the process correctly accounts for the loaded DLLs and their order.
There is very little code which can be added in DllMain which doesn't run the risk of a fail, as any Windows call which may cause IPC can fall fowl of the loader-lock.
If you can create a thread from outside the process, or create a second function you can call directly, then this will be a better solution
The scenario is here:
If a program is executed, at runtime assume it will link to some DLL files, the (master) program/process may or may not create multi-threading function-calls to the functions in DLLs.
Then is there a way that the DLL, of cause besides parameter-passing, can tell whether the master process, who calls the functions within the DLL at runtime, is in a single or multi-thread manner (For instance, by Open MP)?
You can check and compare the current thread ID to detect calls from different threads. You could also implement a DLLMain() function that gets called for every started and terminated thread. I'm pretty sure you can also retrieve a handle to the current process and enumerate the threads running in it. Only the first version will actually tell you if your code is run from different threads though, I think that e.g. WinSock will create a thread for you, even though your program is single-threaded otherwise.
BTW: Consider adding win32api tag and removing C++ tag.
I have a DLL which invokes an application running underneath. This DLL is loaded by several other applications/processes simultaneously.
So, Basically Architecture is:
My Problem is if Application(s) using DLL is crashed, I want to execute an exit sequence in my Base Application and Exit it.
How can I detect that this DLL is no longer used by any application?
Is there any thing like Load Count of DLL which I can keep track of?
Another glitch is I may have to monitor this via a C# application but that is a further thing.
If you can shell an external program to do the check, you can use this:
http://technet.microsoft.com/en-us/sysinternals/bb896656
Your image is not a good model for what really happens in Windows. Every process gets its own copy of the DLL. The code inside the DLL is shared in RAM but not its data. There are ways to share data as well but that's not otherwise common, a memory mapped file is the far more typical approach.
Windows doesn't give cheap way to find out if a DLL is loaded into a process. There is no notification mechanism either. Whatever you do, it has to start with the processes first. That works in C# too, you could use the Process.Modules property.
Just keeping track of the processes you know that load the DLL is probably sufficient, when the process no longer runs then you can safely assume it doesn't have the DLL loaded anymore either. Use the Process.Exited event or use WMI as shown in this answer.
You could host the DLL in the Base Application either and implement your own ref count using shared sections, easy, and often used. As already mentioned, one possibility would be to implemented your ref counting inside your DLL entry point and detect DLL_PROCESS_DETACH, DLL_THREAD_DETACH, DLL_PROCESS_DETACH, etc according to you specifications.
Few months back, I had come across this interesting scenario asked by a guy (on orkut). Though, I've come up with a "non-portable" solution to this problem (have tested it with small code), but still would like to know what you guys have to say and suggest.
Suppose, I created a DLL, exporting some functionalities, written in C++, for single threaded client. This DLL declares lots of global variables, some maybe const variables (read-only) and others are modifiable.
Anyway, later things changed and now I want the same DLL to work with multi-threaded application (without modifying the DLL); that means, several threads access the functions and global variables from the DLL, and modify them.. and so on. All these may cause global variables to hold inconsistent values.
So the question is,
Can we do something in the client code to prevent multi-access of the DLL, and at the same time, ensuring that each thread runs in it's own context (meaning, when it gets access to the DLL, the DLL's global values are same as it was before)?
Sure, you can always create a wrapper-layer handling multi-threading specific tasks such as locking. You could even do so in a second DLL that links with the original one, and then have the final project link with that new DLL.
Be aware that no matter how you implement it, this won't be an easy task. You have to know exactly which thread is able to modify which value at what time, who is able to read what and when etc. unless you want to run into problems like deadlocks or race conditions.
If you're solution allows it, it's often best to assign a single thread to modify any data, and have all others just read and never write, as concurrent reading access is always easier to implement than concurrent writing access (Boost provides all basic functionality to do so, for example shared_mutex).
Can we do something in the client code to prevent multi-access of the DLL, and at the same time, ensuring that each thread runs in it's own context (meaning, when it gets access to the DLL, the DLL's global values are same as it was before)?
This is the hard part. I think the only way top do this would be to create a wrapper around teh existing DLL. When it is called, it would restore the state (global variables) for the current thread, and save them when the call to the DLL returns. You would need to know all of the state variables in the DLL, and be able to read/write them.
If performance is not an issue, a single lock for the entire DLL would suffice, and be the easiest to implement correctly. That would ensure that only one thread was accessing (reading or writing) the DLL at one time.
I'm looking for a way to restart a thread, either from inside that thread's context or from outside the thread, possibly from within another process. (Any of these options will work.) I am aware of the difficulty of hibernating entire processes, and I'm pretty sure that those same difficulties attend to threads. However, I'm asking anyway in the hopes that someone has some insight.
My goal is to pause, save to file, and restart a running thread from its exact context with no modification to that thread's code, or rather, modification in only a small area - i.e., I can't go writing serialization functions throughout the code. The main block of code must be unmodified, and will not have any global/system handles (file handles, sockets, mutexes, etc.) Really down-and-dirty details like CPU registers do not need to be saved; but basically the heap, stack, and program counter should be saved, and anything else required to get the thread running again logically correctly from its save point. The resulting state of the program should be no different, if it was saved or not.
This is for a debugging program for high-reliability software; the goal is to run simulations of the software with various scripts for input, and be able to pause a running simulation and then restart it again later - or get the sim to a branch point, save it, make lots of copies and then run further simulations from the common starting point. This is why the main program cannot be modified.
The main thread language is in C++, and should run on Windows and Linux, however if there is a way to only do this on one system, then that's acceptable too.
Thanks in advance.
I think what you're asking is much more complicated than you think. I am not too familiar with Windows programming but here are some of the difficulties you'll face in Linux.
A saved thread can only be restored from the root process that originally spawned the thread, otherwise the dynamic libraries would be broken. Because of this saving to disk is essentially meaningless. The reason is dynamic libraries are loaded at different address each time they're loaded. The only way around this would be to take complete control of dynamically linking, no small feat. It's possible, but pretty scary.
The suspended thread will have variables in the the heap. You'd need to be able to find all globals 'owned' by the thread. The 'owned' state of any piece of the heap cannot be determined. In the future it may be possible with the C++0x's garbage collection ABI. You can't just assume the whole stack belongs to the thread to be paused. The main thread uses the heap when creating threads. So blowing away the heap when deserializing the paused thread would break the main thread.
You need to address the issues with globals. And not just the globals from created in the threads. Globals (or statics) can and often are created in dynamic libraries.
There are more resources to a program than just memory. You have file handles, network sockets, database connections, etc. A file handle is just a number. serializing its memory is completely meaningless without the context of the process the file was opened in.
All that said. I don't think the core problem is impossible, just that you should consider a different approach.
Anyway to try to implement this the thread to paused needs to be in a known state. I imagine the thread to be stoped would call a library function meant the halt the process so it could be resumed.
I think the linux system call fork is your friend. Fork perfectly duplicates a process. Have the system run to the desired point and fork. One fork wait to fork others. The second fork runs one set of input.
once it completes the first fork can for again. Again the second fork can run another set of input.
continue ad infinitum.
Threads run in the context of a process. So if you want to do anything like persist a thread state to disk, you need to "hibernate" the entire process.
You will need to serialise the entire set of the processes data. And you'll need to store the current thread execution point. I think serialising the process is do-able (check out boost::serialize) but the thread stop point is a lot more difficult. I would put places where it can be stopped through the code, but as you say, you cannot modify the code.
Given that problem, you're looking at virtualising the platform the app is running on, and using its suspend functionality to pause the entire thing. You might find more information about how to do this in the virtualisation vendor's features, eg Xen.
As the whole logical address space of the program is part of the thread's context, you would have to hibernate the whole process.
If you can guarantee that the thread only uses local variables, you could save its stack. It is easy to suspend a thread with pthreads, but I don't see how you could access its stack from outside then.
The way you would have to do this is via VM Snapshots; get a copy of VMWare Workstation, then you can write code to automate starting/stopping/snapshotting the machine at different points. Any other approach is pretty untenable, as while you might be able to freeze and dethaw a process, you can't reconstruct the system state it expects (all the stuff that Caspin mentions like file handles et al.)