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 :(
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
I'm in the process of designing an application that will run on a headless Windows CE 6.0 device. The idea is to make an application that will be started at startup and run until powered off. (Basically it will look like a service, but an application is easier to debug without the complete hassle to stop/deploy/start/attach to process procedure)
My concern is what will happen during development. If I debug/deploy the application I see no way of closing it in a friendly and easy way. (Feel free to suggest if this can be done in a better/user friendly way) I will just stop the debugger and the result will be WSACleanup is not called.
Now, the question. What is the consequence of not calling WSACleanup? Will I be able to start and run the winsock application again using the debugger? Or will there be a resource leak preventing me to do so?
Thanks in advance,
Jef
I think that Harry Johnston comment is correct.
Even if your application has no UI you can find a way to close it gracefully. I suppose that you have one or more threads in loops, you can add a named manual reset event that is checked (or can be used for waits instead of Sleep()) inside the loop condition and build a small application that opens the event using the same name, sets it and quits. This would force also your service app to close.
It may not be needed for debugging, but it may be useful also if you'll need to update your software and this requires that your main service is not running.
I remember reading somewhere that it isn't advisable to use "exec" within the C code, compiled by NDK.
What is the recommended approach? Do we try and push the EXEC code up to the Java-space; that is, so the JNI (or application) spawns the new process, (and where relevant passes the results back down to the NDK)?
First off, it's not recommended to use either fork or exec. All of your code is generally supposed to live in a single process which is your main Android application process, managed by the Android framework. Any other process is liable to get killed off by the system at any time (though in practice that doesn't happen in present Android versions as far as I have seen).
The rationale as I understand it is simply that the Android frameworks can't properly manage the lifetime and lifecycle of your app, if you go to spawn other processes.
Exec
You have no real alternative here but to avoid launching other executables at all. That means you need to turn your executable code into a library which you link directly into your application and call using normal NDK function calls, triggered by JNI from the Java code.
Fork
Is more difficult. If you really need a multi-process model, and want to fit within the letter of the rules, you need to arrange for the Android framework to fork you from its Zygote process. To do this, you should run all your background code in a different Service which is stated to run in a different process within the AndroidManifest.xml.
To take this to extremes, if you need multiple identical instances of the code running in different processes for memory protection and isolation reasons, you can do what Android Chrome does:
Run all your background/forked code in a subclass of Service
Create multiple subclasses of that
List each of these subclasses as a separate service within your AndroidManifest.xml each with a different process attribute
In your main code, remember exactly which services you've fired up and not, and manage them using startService/stopService.
Of course, if you've turned your native code into a library rather than an executable, you probably don't need fork anyway. The only remaining reason to use fork is to achieve memory protection/isolation.
In practice
In practice quite a lot of apps ignore all this and use fork/exec within their native code directly. At the moment, it works, at least for short-running tasks.
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 want to know whenever any application starts. Is there a windows message that I can set a hook for to know exactly when that happens?
If polling is not a problem you could use one of the approaches described in the answers to a related question:
C# Process Monitor
The suggested solutions use WMI or Windows audit process tracking mechanism.
The first message sent to new windows is WM_NCCREATE. But this has nothing to do with the process itself, which is what I suspect you're asking? By definition 'window messages' will start to arrive only after you create a window (using CreateWindowEx or whatever), but that can happen long after the process has started.
You don't say what language/framework you're using. In VC++ and the like you can just use whatever passes for the WinMain function. For VB it would be a Main function in a module.