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
Related
My app fires off a thread specifically for checking the status of a process. It fires every 5-10 seconds:
if(!monitorTask){
MYLog(100,#"Monitor task is dead");
return;
}
dispatch_async(monitorTask,^{ // fuckup here
MYLog(150,#"...Checking iTunes");
However it also seems to hang there every so often:
Any clues how to fix/catch this? The app is beachballing but "running" in Xcode just fine - stuck on this instruction:
Are you sure that monitorTask is of type dispatch_queue_t? See these Apple guides for an example of how to create a serial queue
Though I see in your comment that you are creating the queue correctly.
It is also possible that the queue may be deallocated before you can dispatch to it. You may need to perform some memory management on your queue to ensure that it isn't deallocated before you dispatch.
Lastly it is important to note that serial queues are by-and-large used to protect shared resources. If you are just trying to perform a periodic check on a resource (a task that would never write, and only read), then you are going to be better off using a concurrent queue (you should probably just use one of the 4 given global queues,
Or because you are seemingly perpetually checking throughout the lifetime of the application, you could even look into using a Dispatch Source, more specifically a Timer Dispatch Source
I think this may be an Xcode debugger problem, because I cannot replicate it while running the app outside of Xcode :-/
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 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.
I am developing an application level VSTO 4 Addin for Microsoft Excel 2007 / 2010.
The result is a windows forms based DLL using .Net 4 Client Profile.
Now I have to use a legacy COM-DLL. It is no problem to set the reference and access the COM-Methods via COM-Interop from .Net.
But the the (synchronous) method I need to call can take a minute or longer to get back.
I know your answer:
Use a worker thread...
I have used The Task Parallel Library to put the long lasting operation in a worker task and keep the GUI (Excel) responding.
But: The inprocess COM-Call (in the worker task/thread) still seems to block my GUI-Thread.
Why? Is it because Excel is always running as STA (Single Thread
Apartment)?
How can I keep the Excel GUI responding?
Is there a way to make it really asynchronous?
Thanks for any answers,
Jörg
Finally, I've found an answer to this topic:
I've readed a lot about COM Threading Models and then spoke to the developer of the COM-DLL I am calling as an InProc-Server.
Together we changed the threading model of the COM-DLL:
OLD (blocking): Single-Threaded Apartment (STA), (ThreadingModel=Apartment)
NEW (working): Multi-Threaded Apartment (MTA), (ThreadingModel=Free)
Since we have our own synchronization mechanisms in the COM-DLL, there are no problems caused by the missing synchronization via the standard Windows message queue.
Problem was, that even the UI Thread was idle and even if it did DoEvents, the important windows messages (WM_Paint, etc.) were not delivered.
Now they are. The UI is responding at every time and the call to the COM-DLL is still done in a worker thread (as mentioned above, it's a ThreadPool thread which is used by the Task Parallel Library).