I have some problem with DLL injection and creation thread. So i simply attach my DLL to some process, and in main function of DLL I am trying to create thread. I tried several methods boost::thread::join(), std::thread::join() (after joining target application hangs), CreateThread(...),_beginthread() - my target application is ruining down.
Please, tell me, why I cannot start thread after injection? (DLL injection is successful, I have this problems after starting a thread)
And is it possible to solve this problem?
Where should I look for?
Platform win32, MSVC++
Don't do anything scary in your DllMain as it runs while the loader lock is held. You might get away with calling CreateThread, but the thread won't even start until DllMain returns.
Related
So, I have been working with MAPI API's. In that Whenever I call the MAPIUninitialize api, my application crashes. on further debugging, I found that, IMAPISession::OpenMsgStore is the reason behind the crash, whenever the OpenMsgStore function is executed during the program runtime, my app crashes exactly after the MAPIUninitialize is triggered. which is similar to the discussion in this thread mentioned below, in which soln is not available.
https://peach.ease.lsoft.com/scripts/wa-PEACH.exe?A2=MAPI-L;e6f3847a.0801&S=
I have checked my program for memory leaks, and I'm sure there is none and also, if i comment that particular api, my program doesnt crash, i dont understand the reason for the crash. I have tried all possible alternatives. Can anyone help on this ?
It mostly likely means you still have live MAPI objects. It is also possible that the sequence of MAPIInitialize / MAPIUninitialize is too quick and the common Office run-time is still (asynchronously) initializing when you attempt to shut it down.
Also, not all stores are created equal - IMAP4 is probably the worst.
It is not clear where and when these methods are used. Is it a secondary thread?
Anyway, here is what MSDN states:
A client must also invoke MAPIInitialize on every thread before using any MAPI objects and MAPIUninitialize when that use is complete. These calls should be made even if the objects to be used are passed to the thread from an external source. MAPIInitialize and MAPIUninitialize can be called from anywhere except from within a Win32 DllMain function, a function that is invoked by the system when processes and threads are initialized and terminated, or upon calls to the LoadLibrary and FreeLibrary functions.
I'd suggest playing with the MFCMAPI source code - you can run it under the debugger and see whether an issue is still reproducible or not.
Thanks for your wonderful suggestions. I have fixed the issue, my application actually calls the mapi api's defined in a c++ dll from golang. Because of that, every mapi api defined as a DLL function had different thread ID, When I tied the DLL function calls to same thread using runtime.LockOSThread() / runtime.UnlockOSThread() , it started working, no more crashes.
Ref: https://golang.org/pkg/runtime/#LockOSThread
Do they run on the same thread as the node process or do they run on a different thread? The CPU usage for my node process goes above 100% when I do a lot of sets and gets (and add several event listeners) on firebase. Any ideas why?
There is only 1 main thread in your Node application, all of your code and all library javascript code will run in this thread. When a library attempts to use IO, it may call upon libuv which runs in its own thread. Libraries may also have their own C++ bindings. Without knowing what you're doing and how the 3rd party library is implemented, it's impossible to tell.
I am writing a debugger for a VBScript host. My debugger is an external application. Everything is fine. I get a call to my IApplicationDebugger::onHandleBreakPoint handler. I can call IDebugApplication::ResumeFromBreakPoint and I can step through the code.
Also it is possible to set breakpoints before I run the script. Again IApplicationDebugger::onHandleBreakPoint is called. Also errors are handled. But now I want to set a new breakpoint while I am suspended in IApplicationDebugger::onHandleBreakPoint.
I have a marshaled pointer to IActiveScriptDebug. But when I call IActiveScriptDebug::EnumCodeContextsOfPosition the application blocks. This seams logical for me. The thread with the IActiveScript (IActiveScriptDebug) object resides in a different STA and is still blocked in the debugger as documented.
But what is the correct way to access the Language engine from my debugger thread. All I need is a IDebugCodeContext or IEnumDebugCodeContexts interface for a specific line of code. Am I missing a different interface that I can access to achive the same functionality.
The main solution is to use a IDebugSyncOperation with a call to CreateAsyncDebugOperation. This allows me to contact the blocked language engine that is currently debugged.
The next problem is that some of the interfaces that I need to set a breakpoint (IDebugApplication32 and IDebugApplicationThread) can not be marshaled to a different process.
It is possible to use this interfaces in the process that hosts the VBScript language engine and they can be used inside this application freely.
So the solution for my problem is, to contact the debugged application from my external debugger EXE and perform all the operations to set the breakpoint inside the debugged application.
It was a hard way to find out that some interfaces of the debugging interface are free to marshal to different apartments and others are not.
All this stuff isn't documented at all. Sadly :(
I am writing a client in C# that is communicating with a Windows C++ DLL that uses boost asio asynchronous calls. I have read before that ASIO does not work too well in a managed environment. The VC++ DLL is an unmanaged project that creates an unmanaged thread for the I/O handlers. The C# code creates a background thread to handle sending messages to the C++ DLL via pinvoke. My question is - can the call to the boost::asio::async_write method be on a managed thread? Or, does it have to be on an unmanaged thread?
It will help simplify the logic and processing if I can make the call to async_write on the managed thread. But, I'm worried about what might happen when the .NET garbage collector runs and stops the threads. I don't know if ASIO will be able to handle that or not. I'm not passing any pointers to data defined in the C# code, so that should not be a problem.
The notion of a "managed thread" is a weak one, the operating system only supports one kind of thread. A thread that runs managed code isn't special, managed code gets translated to the exact same kind of machine code that a C compiler generates. The only difference is that the CLR knows about the thread and will have a reason to have a look at its stack when a garbage collection occurs. Necessary to find stack frames of managed code that may contain object references.
It will not be interested in any stack frames that belong to native code, it simply ignores them. And yes, the thread may be paused while the GC performs the search but only if it is currently executing managed code. Native code keeps running, it will only block when it returns back to a managed method if a GC is in progress. This pause isn't otherwise different from any other kind of reason a thread may pause, including losing the processor for a while when the operating system scheduler runs something else.
So using boost::asio is fine, nothing goes wrong. Just as the many other ways that a managed program can execute native code, including operating system calls. The only detail you'll want to take care of is making sure that your code gets compiled without /clr in effect. Compiling boost code to IL works fine, it just isn't very efficient.
I have a mixed mode 64-bit managed app that creates a DirectShow filtergraph via a managed interop assembly. I need to catch the thread creation for one of the unmanaged filter threads (could hook Quartz.dll, but that is too painful). Which SDK/C++ runtime functions should I put function breakpoints on (CreateThread, _beginthread, etc) -- or is there a better way to do this?
One way to do this is to create some dummy DLL for your app, that implements DllMain and its 4 messages. One of the messages, DLL_THREAD_ATTACH would be the place to stick a breakpoint or whatever code.