I was hoping somebody here had some insight into what could be causing this problem. I've implemented several COM extensions for Explorer that provide ShellIconOverlays and a ContextMenu, and the overlays work perfectly. The Context Menu works fine when I click on the desktop but when I right click in any explorer instance, I can see the interface being queried in the debugger and an instance of IShellExtInit being generated but the initialize function doesn't get called in the explorer instances, but it is called fine from the desktop and a ContextMenu item is queried immediately after.
Has anybody here seen anything like this before?
If you're debugging a shell extension, chances are that you've had occasions to terminate the running explorer.exe process and start a new one. When you started a new one, was it running with the same integrity level as the original?
Do your Explorer settings say to browse files in a new process? If so, is that process running with the same integrity level as the original?
Also, since you're running a debugger, chances are that you built a debug build. Does explorer.exe sometimes try to load the debug build of your DLL and sometimes try to load the release build of your DLL?
OK, I run into the exact same problem here, and it turns out that the issue has to do with
ThreadingModel = Apartment
Basically, what I think you are experiencing, is that the second thread of explorer.exe (desktop runs in STA thread) uses the default (legacy) ThreadingModel - and expects your COM to implement IMarshal to do IPC. Apartment ThreadingModel allows multiple instances of your IShellExt class to co-exist.
Caveat - If you are using ActiveQt to develop Context Menu Shell Extensions, there are few more tricks to use.
Related
We have a bigger software running on Win CE6 without problems. The core functionality is implemented in a COM server DLL that provides connection points. The COM client program registers event handlers for the connection points on program startup to get status notifications etc. On program exit it unregisters the handlers by calling the corresponding IConnectionPointImpl::Unadvise methods.
Now, we are porting the program to run on Win EC 7. The new Board Support Package (BSP) for Win EC 7 works well. There are also different versions with different options, created at different times with different sources from Microsoft, but our software always show the same issue.
On program startup, ~10s after launch, IConnectionPointImpl::Unadvise is called unexpectedly on all registered event handlers. We only have one method in our source code that calls IConnectionPointImpl::Unadvise and this is definitely not executed.
The issue appears ~95%, but sometimes the program starts and runs without problems. We cannot use the Debugger because of the size of the program, the performance is very poor.
We guess, that the COM runtime calls the IConnectionPointImpl::Unadvise methods for some reasons. But we have no idea, how to prevent this.
Has anybody observed the same issue? Is there a solution/workaround available? Thanks.
So we finally found how solve this problem.
We remove our dependency on MarshalByReObject and replace it by a proper implementation of ISerializable.
That allow us to load properly inside custom AppDomain our assembly and events are not loose anymore.
But this has a side effect on path where assembly a configuration file are loaded. To solve this we also implement an AppDomain.AssemblyResolve event which allow us to redirect the loading in a proper place.
I hope this can help you ;)
Hi,
I'm relatively new to C++ and WinAPI. So far I've managed to create an application, that is using the CreateProcess function and a STARTUPINFO structure to create a new desktop, launch inside that new desktop a new explorer.exe process and switch to it.
Next, because I wanted to be able to switch at any time between these two desktops, at a press of a key (LCTRL in my case), I've made another application that uses the SetWindowsHookEx function to create a global hook for the keyboard.
Because the hook is active only in the calling destkop, in the first app, using CreateProcess, before creating the explorer.exe process and switching to the new desktop, i've launched the executable of the second app twice: once in the current desktop and once in the new one.
Everything is working fine, I'm able to make the switch between desktops at any time, but now I've been asked to do something about the structure of the processes launched, somehow, to make the seconds app code run inside the first one, without creating a new process. Because this is my first post, I can't upload a snippet of the process tree, but the procexp application from live.systernals is showing the following structure:
---FirstApp.exe:
-------------SecondApp.exe (original desktop)
-------------explorer.exe (new desktop)
-------------SecondApp.exe (new desktop)
So basically, my question is: can I make the code of the application that hooks the keyboard run in the same thread as the FirstApp? This implementation, an app that starts these three processes, and the second app that hooks the keyboard, was my idea (I was not requested to do it this way, I was only asked to create a new desktop and switch between them), so I am open to suggestions towards making a better implementation for this problem too.
It could be possible since there is little difference between a DLL and an EXE on Windows, so I think you could try to export the routines from SecondApp and then import them in FirstApp with LoadLibrary.
But IMHO the clean way to do that is to break SecondApp in two pieces : a DLL containing code that actually does the job and an EXE that would be a simple frontend calling routines from the DLL.
That way, it will be trivial (and portable across different versions of Windows and SDK) to call the routines of the DLL from FirstApp.
I have written a simple vc++ background application. What am trying is like a watchdog service that could monitor if the application is running or not. If the application crashed then the service should start the application
For creating a setup through windows installer am using only the app.exe and app.dll.
Is that possible to create this watchdog - service in the exe itself ?
Unfortunately I have no idea of how to write such a program, does anyone have some example code that would demonstrate this technique please?
if so then how to make the default exe and watchdog exe as a single application to install ?
Your best route would be to create a separate service to act as the watchdog. Technically, it's possible to have the service and the "real application" in the same executable. You can differentiate between the two depending on how the exe has been started, but it will make maintenance quite difficult.
This article might be of interest.
Here - http://yadi.sk/d/EtzBRSMi3FqVH - is my implementation of WatchDog app, working in systray. Do not mind that it's written with Qt - the main functionality is with WinAPI.
This app is watching in processes list for several processes and restarts them if can't find. The second feature is that it monitors all windows in system for suspicious window title (for ex. "'My Great App' causes a system error and will be closed. Send message to developers ?") and, if find, restarts them too
P.S. I didn't i18n it, but I think there will no troubles )
Update: (according to #CodyGray comment)
Here's pastebin's links: WatchDog.cpp and WatchDog.h
Such a watchdog can be set up to, for example, write to a file every minute (or whatever). If the file hasn't been updated in two or more minutes then there is most likely a deadlock in the application and it has to be restarted.
I have a IE BHO plugin that I only want to be enabled when the user launches IE from my program (The program starts IE using CreateProcess()).
I don't want this BHO to be enabled when a user launches IE from outside my program, as that would mean any problems in the BHO could potentially mess up the user's normal browsing experience.
What's the best way to do this?
One way would be to register the BHO, launch IE and then quickly unregister the BHO. This seems kind of messy though, as a crash in the program that launches IE could cause the BHO to remain registered.
Your approach is very error-prone, I advise against it. Instead, your BHO should always load with IE, but by default it should do nothing. What you need then is a way to tell it "start filtering" or "start recording" or whatever.
You've got lots of choices from there. The simplest is a flag somewhere in the environment (a semaphore, a disk file). You can have a special url, like mybho:start that it watches for.
I've done this many times, it works.
Edit Yes, the BHO will be loaded into memory, together with any DLLs it depends on (though you can wait and load them only when needed via LoadLibrary()).
I have an application for which I do not have the code, and a dll for which I do have the code. I need to be able to debug into the dll, but lacking the source for the exe, how do I do this?
The dll code is mfc c++; I believe that the main app is the same thing as well.
I've tried doing a 'set target application' deal, where I set the application that the dll will be called from, and the application crashes a horrible, horrible death when called that way. I don't know if the fault lies with this dll or with the executable for that behavior, and it's just one of the myriad things I'd like to solve.
I'm thinking that there should be some call to allow the dll to spin indefinitely until a debugger is attached to the process, at which point I should be able to debug the dll by attaching to the process. Does that make sense? Is there a better way to do this?
I used to use the DebugBreak function for this. You could have it called conditionally based on the presence of a particular file, perhaps.
#ifdef DEBUG
if (... file exists...) {
DebugBreak();
}
#endif
This will halt application execution until you attach a debugger or terminate the app.
If the application is linked against a non-debug DLL and does not have debug symbols itself, this isn't really likely to be fruitful. You might want to look here for information on using windows symbol packages to help you if you're curious about what's going in inside windows DLL's, but by and large, an application which does not have debug info and which you can't compile isn't debuggable in any meaningful way.
There is a registry setting called ImageFileExecutionOptions that can be set up to launch a debugger whenever your DLL is loaded. I used to use it to debug ISAPI extensions. Here is a link to a decent blog entry about it.
__asm int {3};
in your DLL main. Then attach a debugger to the process?
If this kills the process, then it probably has it's own int3 trap and is quitting. Are you trying to debug a copy protected game or anything like that? As they tend to do that kind of tricksy behaviour.
With a DLL project, you should be able to tell Visual Studio to start debugging and it will ask you for an executable name. Enter your exe there. I've done this a lot for when I've worked on DLL code that was called from another process. Works for straight DLLs as well as COM components.
It might also help to set some breakpoints in your code ahead of time if you have an idea of where the problem might be.
Update: Since that does not work for you, the only other thing I can think of would be to attach to the running exe, but that could be problematic if your code gets loaded before you have a chance to get in there.
Wait until a debugger is present:
while(!IsDebuggerPresent())
{
Sleep(0); // yield
}
MSDN Documentation: IsDebuggerPresent().
Ensure that the application is indeed using the DLL that you built, in debug mode, with symbols. You can verify this by using a program such as Process Explorer (in this application, enable the lower pane in the View menu and select DLLs).
Then, in Visual Studio's Debug menu, select "Attach to Process", and select the application that uses your DLL. Your debug breakpoints should become filled in, if and when your DLL is loaded.
I recently had to use one of the methods listed here:
http://blogs.msdn.com/greggm/archive/2004/07/08/177418.aspx
Does that help?
Here's a simple solution: add a Sleep(10000); in DllMain (or some other startup code) and then use Tools / Attach to Process to attach your debugger while the code is sleeping.
I'm thinking that there should be some
call to allow the dll to spin
indefinitely until a debugger is
attached to the process, at which
point I should be able to debug the
dll by attaching to the process. Does
that make sense? Is there a better way
to do this?
Why not do it the way you are describing it? Just start the application that you want to debug. Attach the debugger to it, either through Visual Studio or simply by right clicking on the application in the task manager and selecting Debug. Once the debugger is attached, set a break point with F9 at suitable location in your dll code.
I've tried doing a 'set target
application' deal, where I set the
application that the dll will be
called from, and the application
crashes a horrible, horrible death
when called that way. I don't know if
the fault lies with this dll or with
the executable for that behavior, and
it's just one of the myriad things I'd
like to solve.
Starting a process inside the debugger causes Windows to enable the NT debug heap. It sounds like the application or DLL has heap corruption or relies on the value of uninitialized heap memory.
You can disable the NT debug heap by setting the environment variable _NO_DEBUG_HEAP to 1 (on XP and later). This may make it possible to get the application to not die a horrible death when started from the debugger.
Starting the application outside the debugger will also result in the NT debug heap being disabled, and attaching a debugger later will not enable it.