This is somewhat complex issue with several questions. Feel free to answer only the questions to which you have an answer.
I have a task to create minidumps in case of Windows exceptions for several of our components, and to support XP SP3 as minimal OS. Components include:
Standalone C++ apps
CSP and PKCS11 libraries (DLL's) to be used in known browsers
one UI and one non-UI service
Static libraries, which are used in all previous three points
The requirement is to have something like WER (from XP onward), but to send reports to dedicated vendor server instead of to Microsoft's current Winqual equivalent. It would be really nice the reporting functionality could be wrapped in one static library.
There are issues, though. DLL's are special beasts. How to generate a report only if fault happens in DLL code? Services may also require some special handling, of which I'm currently unaware.
First of all, is there a known open-source library that could help me with this task? If not, I'd have to roll my own.
My first thought is to have a sleeping watchdog thread in each of my modules. This thread just waits on an event, which will be set from unhandled exception filter. The thread would generate the report using MiniDumpWriteDump, send it over the internet and then finish, and in the mentioned filter we would wait for the thread to end, and then terminate the process. Any thoughts on this solution? For instance can Windows service under local system account access the internet at all?
You don't need to create a thread that "waits for an exception".Just register your own Exception handler using UnhandledExceptionFilter. Look at this URL, it is well explain how to take MiniDumpWriteDump when an exception occurs.
Windows services that run under local System credentials don't have network access.
Related
We are having some strange issues on Windows Server 2012 (both normal and R2). Every once in a while (seemingly randomly) we start getting strange errors with all the programs on a server (API calls to Process32Next fail for instance). These occurrences seem to be a associated with one or more of our old ActiveX EXE (VB6) programs suddenly showing 'Embedding' in their description in the process viewer (task manager or Process Hacker). The problem goes away when everyone logs off. I cannot find anything much on Google about this. These programs have been around unchanged for over a decade and I cannot see how ANY program could affect every other program on a server but I am hoping that understanding why the Embedding description shows up might help lead to a solution.
Also, sometimes the name of the process is blank as well.
ActiveX EXE is another name for Automation Server. This is one of several technologies built on top of COM that fall into the OLE 1.0, OLE 2.0, and OLE custom control (a.k.a. ActiveX) categories. OLE stands for Object Linking and Embedding.
My guess is that wherever you are looking this term "Embedding" is being used to indicate an Automation Server. So it probably has no direct bearing on your issues.
I suspect this is a case of "looking where the light is good."
You may be running into some issues related to Session 0 Isolation, User Interface Privilege Isolation, or both. Or more likely you might have DCOM/Automation activation settings incorrect for one or more of these programs.
You might start by looking at the definitions for these servers in DCOMCNFG.EXE. People often rely on defaults and that may not be what you should have. Some of these might be defined in COM+ which means additional rules. Some of these interact with user rights and group membership.
But we have far too little specific information to really be of much help here.
I'm interesting in gathering usage metrics for an application that I did not write and have no control over. This is a applicaiton running on Windows.
My plan for this is to register a global windows hook for mouse and keyboards events, and record those events for windows that have pre-determined titles or other identifable attributes.
Using this data, I hope to be able to determine how a user uses the application in question. What buttons they click and when, as well as common workflows. Etc.
Any thoughts on this idea? Are there 3rd party products or libraries that would facilitate this solutions that do not require modification of the existing application?
I assume (hope) this is for something like usability experimentation and not nefarious purposes.
The approach you outlined seems reasonable. The drawbacks of global hooking are:
It's a burden on every process, since your hook code will be injected into every process.
It can run into security barriers. For example, if you're hooking from a medium integrity level app, I don't think you'll be able to hook a high integrity level app. Also, you're essentially creating a keylogger, so don't be surprised if some anti-malware app flags you as possibly spyware.
You may need a 64-bit version and a 32-bit version.
One way to mitigate the impact you have on the machine is to use a more targeted hook: find the particular process you care about, enumerate its threads, and hook only those.
Spy++, a developer tool for tracking Windows messages, does much of what you want, but I'm not sure if you could leverage it for your purpose. I'm not aware of any other tools or frameworks for doing this kind of instrumentation.
I am adding an event driven plugin api to a web based system I am working on.
Should I wrap the plugin calls in a try/catch to make sure they don't crash or should I leave this up to plugin developers to take care of.
Also, some of the plugins may change the data I pass them, should I re-validate all the data or trust the plugin developers not to break anything?
You should not let your program crash.
If you can protect yourself from innocent mistakes by plug-in writers, you should do so - both by handling exceptions and by revalidating modified data that your code must reuse.
What you do when you find a problem (exception or malformed data) is up to you - unloading the plug-in and not using it again until it is reloaded might be sensible in production mode. For plug-in developers, providing good diagnostics of what went wrong would be sensible - possibly even crucial to gaining widespread acceptance (lots of people writing plug-ins for you). If the other programmers cannot resolve problems effectively, they may not continue to try.
Should windows crash in case a third party app crashes or should it incorporate some kind of process isolation?
Should firefox crash if a plugin crashes?
There's your answer. Never trust 3rd party to to their job as they should.
There is a nice addition to Firefox, which prevents a plugin to crash the main application (e.g. Flash).
The main application must always have control. As the name implies a plugin is one among others and should not be able to stop the main + other plugins. Also, by keeping control over plugins, the main application may still provide directions to the user to either
uninstall the plugin
look for an alternative etc...
Keeping control allows the user to be aware of what is happening and who is responsible.
In Firefox I like that I'm able to know who made an attempt (kind of) to crash the application.
This way you as the main application developer, you are not criticized for a bad job you didn't do in the first place.
As for control of data
It depends on the application and the kind of data. If the data has an impact over the other plugins and the main application itself, it should be controlled, adjusted or fixed.
As an analogy .. would you accept any user data without validating it?
In this case I see try/catch as the program execution analog of user validation
When we write standalone program and prevent it from crash by using some kind of global try-catch, we successfully hide a bug details, preventing these bugs to be fixed. Generally, unexpected unhandled exception should crash the program. This is the way to debug such exception just when it is thrown, or generate crash dump for post-mortem debugging.
Program which loads third-party plugins, obviously, must be protected from plugin crash. On the other side, it is a good idea to give chance to plugin developers to fix their bugs, allowing the whole program to crash. I would consider to add some special running mode to such program, this can help to plugin developers. Of course, such mode should not be available for normal users. In the normal mode I would catch all plugin bugs, preventing the hosting program to crash, but every plugin crash should be logged with maximum possible details.
There isn't really a language-agnostic answer to this question, but I'll assume that the plugin is some kind of dll.
If you can avoid trusting the plugin, there are some potential benefits from avoiding it. If nothing else it helps isolate bugs, but also it provides your user with some protection from malicious plugins, and helps with the reliability and robustness of your app.
However, it is fairly difficult to avoid trusting a plugin. Depending on OS, are you going to run it in its own process with minimal privileges, no filesystem or sockets access, restricted access to resources such as memory and CPU time, a monitor that will kill it if it appears unresponsive, communicating with your process only through a pipe? If not, then some buggy plugin will find a way to ruin your afternoon, meaning that you've "relied on" its correctness whether you intended to or not.
Catching exceptions implies that you're running the plugin in one of your application threads. So you are trusting it. You can't "make sure it doesn't crash" if it has the ability to do some OS-specific thing that will make the kernel shut down your process with extreme prejudice.
All that said - on the specific issue of catching exceptions, callers should catch exceptions if and only if they can do something useful with them.
I'd catch them if the plugin is doing something non-essential (e.g. rendering one component of a web page), or let them go if the plugin is doing something absolutely essential to the program (for example if it's a video codec in a command-line transcoding program, maybe I'd catch the exception and rethrow it after logging an error "blaming" the fault on the plugin. Otherwise I'd handle it the same as any other unexpected error in the program).
We're starting a new custom project right now from a client and one of the requirements is the process cannot be terminated unless the system is shutting down, restarting, or logging-off.
This application monitors the USB interface. We will be using WMI to query the device periodically.
The client want's to run the application on Windows XP Operating System and doesn't like installing .NET. So we targeted Visual Basic 6 as our language.
My main concern is this application cannot be terminated. Our Project Adviser talks about Anti-virus and yes, some of the anti virus cannot be terminated. I was thinking how to do the same in Visual Basic 6. I know there will be API involved on the project but where should I go? so API is ok with me.
I saw some articles that converts the EXE to a SERVICE, create Windows Service in Visual Basic 6, etc.
So please .. share your thoughts.
If you want to be evil, you can call the (officially) undocumented RtlSetProcessIsCritical NTDLL function. This will immediately BSOD the machine if your process is terminated.
You cannot create a process that cannot be terminated without some sort of kernel-mode hooking, which involves writing a driver. You might want to look into Rootkits: subverting the Windows kernel if you're interested in that. However, even with kernel-mode hooking there are still numerous ways to terminate processes. The alternative is to use user-mode hooking, easily bypassed but enough for very simple projects.
The solution you want to use will depend on how far you want to go with the termination protection. And even if you do succeed in preventing process termination, there may be ways of preventing your application from working properly - e.g. killing the WMI service.
I think you want to look at writing an NT Service.
More info here: http://www.montgomerysoftware.com/CreatinganNTServiceinVisualBasic6/tabid/161/language/en-US/Default.aspxlink text
It's really frustrating coding in VB6 right now specially I dumped my head in C# for 2 years though I coded in VB6 for 5 years..
Moving back is a pain as if I am starting a new programming language.
To be honest, you are trying to do something in VB6 that it really isn't that great at.
When you say 'cannot be terminated' - what do you mean by that? There are several levels there:
a) App shows a window but the user cannot close it with the X button, or it does not show one
b) App shows no windows or maybe sits in task tray
c) App shows no windows and cannot be shut down from the Applications tab of task manager
d) App cannot be shut down from the process list of task manager
(a) and (b) are probably easiest to do in straight VB. (c) is still possible, but getting uglier. (d) gets you into hack territory and would almost certainly be frownd upon if you did manage it.
If you really need to stop users closing then you can probably hack it to a greater or lesser degree, but the real answer is as the others have said - a system service (this is exactly the srt of thing they were intended for). However that is one thing that VB6 isn't good at so the best solution to your problem is c#.
I would like to create events for certain resources that are used across various processes and access these events by name. The problem seems to be that the names of the events must be known to all applications referring to them.
Is there maybe a way to get a list of names events in the system?
I am aware that I might use some standard names, but it seems rather inflexible with regard to future extensibility (all application would require a recompile).
I'm afraid, I can't even consider ZwOpenDirectoryObject, because it is described as needing Windows XP or higher, so it is out of question. Thanks for the suggestion though.
I am a little unsure about shared memory, because I haven't tried it so far. Might do some reading in that area I guess. Configuration files and registry are a slight problem, because they do tend to fail with Vista due to access problems. I am a bit afraid, that shared memory will have the same problem.
The idea with ProcessExplorer sounds promising. Does anyone know an API that could be used for listing events for a process? And, does it work without administrative rights?
Thank you for the clarification.
There is not really a master process. It is more of a driver dll that is used from different processes and the events would be used to "lock" resources used by these processes.
I am thinking about setting up a central service that has sufficient access rights even under Vista. It will certainly complicate things, but it might be the only thing left facing the problems with security.
No, there is not any facility to enumerate named events. You could enumerate all objects in the respective object manager directory using ZwOpenDirectoryObject and then filter for events. But this routine is undocumented and therefore should not be used without good reason.
Why not use a separate mechanism to share the event names? You could list them in a configuration file, a registry key or maybe even in shared memory.
Do not mix up the user mode ZwOpenDirectoryObject with the kernel mode ZwOpenDirectoryObject -- the kernel mode API (http://msdn.microsoft.com/en-us/library/ms800966.aspx) indeed seems to available as of XP only, but the user mode version should be available at least since NT 4. Anyway, I would not recommend using ZwOpenDirectoryObject.
Why should configuration files and registry keys fail on Vista? Of course, you have to get the security settings right -- but you would have to do that for your named events as well -- so there should not be a big difference here. Maybe you should tell us some more details about the nature of your processes -- do they all run within the same logon session or do they run as different users even? And is there some master process or who creates the events in the first place?
Frankly, I tend to find the Process Explorer idea to be not a very good one. Despite the fact that you probably will not be able to accomplish that without using undocumented APIs and/or a device driver, I do not think that a process should be spelunking around in the handle table of another process just to find out the names of some kernel objects. And, of course, the same security issues apply again.
ProcessExplorer is able to enumerate all the named events held by some specific process. You could go over the entire process list and do something similar although I have now clue as to what API is used to get the list...