Is it possible programmatically using VC++ to wait for the value of specific memory address to change and then do something with it without the infinite loop? To get the value I'm using ReadProcessMemory function.
You could do it the same way Visual Studio does data breakpoints:
As long as your program will only ever run on X86 processors, and as system administrator, you should be able to achieve this using debug registers. However, these are only meant for debugging purposes, and should not be used in production.
There is a function called WaitOnAddress which is documented here: https://msdn.microsoft.com/en-us/library/windows/desktop/hh706898(v=vs.85).aspx
It signals a waiting thread when the address is changed within the current process. I don't necessarily think this is the answer you're looking for if you're referring to doing this via IPC. If you are doing this via IPC though, you could do code injection and accomplish this with the same function.
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
I am currently using
NtQueryInformationThread(.., ThreadQuerySetWin32StartAddress, addr, ..) for getting the thread address in addr. The msdn doc says
NtQueryInformationThread may be altered or unavailable in future versions of Windows
Also,
Note that on versions of Windows prior to Windows Vista, the returned start address is only reliable before the thread starts running.
What is the suggested method for retrieving a thread's address?
The NtQueryXxxx group of functions are internal Windows kernel functions that were undocumented. Until Microsoft was forced to document them in the settlement with the USA Department of Justice. They did so, but reserved the right to alter their implementation in any future version of Windows, necessary to allow them to innovate on Windows. And reserved the right to not have to make the function actually useful beyond its intended use in the kernel.
The warning is very accurate, you will not get a usable thread start address from this function after the thread was started. It will point to the real start address, an internal helper function named __RtlUserThreadStart() in ntdll.dll. You can see it back in any stack trace when you've got debugging symbols for Windows. The same start address for every started thread.
The writing is on the wall. Don't use it.
I have a small C++ dll that has 2 callback functions that retrieve information from another dll.
These 2 callback functions are being called repeatedly in more than 1 thread.
They both add information to the same global Cstring variable.
I have another function that the program that uses this dll will call that reads this variable.
It is rare, but sometimes I get a crash and its definitely due to this global variable being read/written to at the same time by 2 different functions.
I am not very experienced with multithreads, so I don't really know what to do.
Any suggestions?
here is a previous question I posted about the same problem with a bit more info..(and some of the code).
One of the users assisted me in confirming that it was a multithread issue and we didnt get much further than that.
C++ DLL crash (reading/writing crash related I think)
Have a read of Thread Synchronization for Beginners.
If you're using MFC then CMutex may be appropriate.
You have to create a critical section on this variable. In Windows, you can do it by using Mutex Objects.
I have embedded Lua in an Objective-C application using LuaObjCBridge. I need to know how to stop the Lua process if it taking too much time (infinite loop?).
Would running it in a separate thread help?
The usual way to do this is to use lua_sethook to schedule a callback every count VM instructions; when the callback lua_Hook function occurs after a excessive time your hook function can raise an error forcing control to your protected call.
Doug's answer already provides the default necessary to restrict normal lua code execution. If you need to limit this for security reasons, you should know that there are known ways to use lua library calls, such as string pattern matching functions, to create practical infinite loops. The instruction count hook won't catch these for you since the lua instruction count is not incrementing while the c function call is executing. For a solution of this calibre, you need OS-level restrictions (separate process, interrupt from SIGALRM?)
For OS-level restrictions like kaizer.se mentions, one good approach for running Lua stand-alone on *nix systems is to use ulimit -t 1 to restrict the Lua process to one second of CPU time. This is the approach the CGI script that powers the live demo on Lua.org uses.
For an application like the one you described, using your environment's thread facilities is the best option.
Is there any way I can have a thread branch off into its own independent process? I know there's the CreateProcess function but as far as I can tell, you can only run external applications with it. Is what I'm asking for at all possible?
It is possible.
You could call CreateProcess with a dummy application and with the CREATE_SUSPENDED flag so it doesn't run immediately. Then you can use VirtualAllocEx to allocate memory space in the created process and WriteProcessMemory to write code and data into it. And then unsuspend the process to run it.
You can also use CreateRemoteThread to create a process running within the context of another existing process.
So what you want to do is possible, but it's really not a simple thing to do in a windows environment so you'd have to have a really good reason to want to do it.
That's not possible under Windows. On Posix platforms the desired effect could be achieved by fork()ing.