We are in the process of setting up surround scm as our source control program. We created a trigger which will run when changing the state of a file/repository. When we run it on many files the server gets several werfault.exe processes in the process list. I realize its windows error reporting, however, there is no popup. I'm trying to determine the cause of the error... is there a specific log I can check, or a debugging technique I can use? I don't believe it will be possible to debug directly on the server it runs on.
Thanks
WER faults end up in the Event Log, so that might give you a tiny clue, though it's usually not enough info to tell what went wrong. Maybe you want to add more logging to your trigger application, or have it run userdump.exe when it's about to crash (see AppDomain.UnhandledException event) to a specific folder - that way you can open up the crash dumps later to figure out what went pear-shaped.
What was happening was that we set a trigger on certain events and the trigger calls the handling exe simultaneously, which was swamping the server. We're now using an alternate solution with a windows service so we can control the max amount of simultaneous trigger executions.
Related
I am writing a small utility application to monitor my clipboard. This at current works quite well, but a friend has told me that it randomly will stop showing alerts upon clipboard change, and that restarting fixes it.
I couldn't reproduce, but eventually I ran into it myself - the application had stopped recieving WM_DRAWCLIPBOARD events.
How can I tell when my application has been removed from the listener chain?
This is one of the hazards of the clipboard listener chain: One bad application can damage the chain. Instead of using the SetClipboardViewer function, use AddClipboardFormatListener which does not have this problem.
If you are debugging an application that uses SetClipboardViewer and the application crashes or you stop the application in the debugger, or in some other way bypass the restoration of the clipboard chain, there is performance degradation in Windows, to the point that seemingly unrelated features of Windows, such as Alt-Tab, or restoring a minimized window, stop working. They come back if you restart Windows.
An application that inserts itself into the clipboard chain this way should be calling ChangeClipboardChain during Dispose of the main form, or at another appropriate time, to avoid this issue. Dispose isn't called if you stop the app in the debugger.
I have not tried AddClipboardFormatListener; first time I've heard of it; I'm going to try it to see if I can avoid the issue in my own app while I'm debugging.
To capture the messages written in output window in VS 2010 , trying to intercept a message leading to a bug.
the message that i'm trying to intercept :
A first chance exception of type 'System.Runtime.InteropServices.SEHException' occurred in OpenNETCF.Desktop.Communication.dll
Disconnect
after that when i connect the device the app freezes, with no exception.
How i could capture output window messages or redirect them to a string ? can i intercept when i will use this app in production mode ?
I have tried to capture console Messages but i got nothing apart the console.writeline called from the app , so i think that these messages are not console.writeline calls.
If you are debugging the application then to get the debugger to break when a specific exception is first raised (1st chance exception/thrown) you can tick just the specific exception you want, instead of the whole set of exceptions in Runtime.InteropServices.
See the screen shot below:
If your application isn't currently running in a Debugger, then you can get a debugger to attach to the already running process...by using "Attach to Process"...however, that is not normally done in a production environment.
If you want to analyze your application in a production environment i.e. you can't stop your application or run it in a debugger...then the best way to do that is when the exception occurs to get a "dump" created of the process...which you can then analyze offline in either WinDBG or Visual Studio by loading the saved .dmp file.
The best way to set things up is so that a "full dump" file is automatically created when the exception occurs by using DebugDiag.
http://blogs.msdn.com/b/kaushal/archive/2012/05/09/using-debugdiag-to-capture-a-dump-on-first-chance-exception.aspx
It's also possible to manually do a "mini-dump" of your application process by right clicking on the process in Task Manager and doing create Dump File. Doing manually however, means you are a lot slower at capturing the state close to the time of the exception, and also a "mini-dump" is less useful than a full-dump.
There's a good tutorial here on how to diagnose problems in a production environment:
http://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment
My WPF app uses Log4Net to record messages to the event viewer. This is working great on most machines. However, there are two machines in my office where there are problems. One is a physical Windows 7 machine with 2 GB of ram, the other is a virtual machine running XP, which also has 2 GB of ram.
The problem is that even though the users are logged in using accounts with administrator rights, the system won't let them create the custom event log that I set up for my application. This is causing my program to die.
I can add error handling on all of the Log calls, but my feeling on this is I shouldn't. The messages are being logged in the catch handler for another error that already occurred. Just what am I going to do with the error information if it can't be logged?
In any event, I tried to create the custom event log on the XP virtual machine yesterday and it still wasn't created. What exactly do I need to do to get the custom event log created on these two machines?
Tony
It turns out that the problem wasn't in the logging code at all. My program uses WPF for the GUI. It's start-up sequence does the minimum amount of work on the UI Thread so it can display the UI as soon as possible.
The rest of the initialization is done on a background thread. I knew that an error was occurring, but I couldn't find the custom error log in the list of logs in the Event Viewer. It turns out that my code didn't find some data in the database that it needs and was trying to report the error. This is a 2 step process which involves first recording the error to the log and then displaying a custom MessageBox dialog. I was getting a XamlParseException when the program was trying to display this dialog.
To make a long story short, the problem that was crashing the program was the XamlParseException. This was thrown because I was calling the custom MessageBox's Show method on the background thread, not on the UI thread. Because I couldn't find the custom event source in the event viewer, I couldn't find the error, so I assumed that the error was a permisions issue.
By the way, I did try to create the event log manually at one point, and yesterday I checked the registry and did find the entry for the custom event source.
There is one other machine here that is having the same problem. I'm sure it's the same exact issue. I'm adding logic to the error handling to make sure that the custom MessageBox is always called on the UI Thread so the program won't bomb like that if the same issue recurs.
We would need to see how you tried creating the event log on the XP machine...
Generally, you need to read this: http://msdn.microsoft.com/en-us/library/49dwckkz(v=vs.80).aspx
Particularly the note discussing when to create your custom event log:
"In general, create the new event source during the installation of your application. This allows time for the operating system to refresh its list of registered event sources and their configuration. If the operating system has not refreshed its list of event sources and you attempt to write an event with the new source, the write operation will fail. If creating the source during installation is not an option, then try to create the source well ahead of the first write operation, perhaps during your application initialization. If you choose this approach, be sure your initialization code is running with administrator rights on the computer. These rights are required for creating new event sources."
Try creating the custom log in advance of the first logging event to use it.
How can I create a separate crash handler like GoogleCrashHandler?
This is appropriate for unmanaged code (all of Google's code is). The usual scenario is that an app opens a named pipe to talk to the crash handler and tells it to start watching the app. The crash handler then adds a named event to a list it watches. When the app crashes, an exception filter inside the app, installed with SetUnhandledExceptionFilter() will gain control. That exception filter then turns on the named event. The crash handler immediately notices and it takes a minidump of the crashed app and uploads it. And terminates the app.
A crash handler like this is necessary because a crashed app cannot be trusted to still be able to function correctly when it suffered a heart attack. Microsoft has one too, it is built in Windows. Called WER, Windows Error Reporting. That's the source of the dialog you see when a crashed app asks you if it is okay to let Microsoft know about the crash.
This is approach is unnecessary for managed apps. They almost never die from the kind of hardware exceptions (like AccessViolation) that unmanaged apps die from. Just write code for the AppDomain.UnhandledException event.
The Google Crash Handler seems to be an application that gets notified when certain things occur in other applications.
"GoogleCrashHandler.exe runs continuously on your computer if you've selected to send anonymous usage statistics and crash reports to Google for certain Google software, like Google Chrome. It helps send crash details to Google when your Google software unexpectedly shuts down. We use this data to help determine how to prevent these errors from happening in the future."
I would create a Windows service, that runs in the background, that you communicate with through named pipes, tcp, file drop, or any other good method.
The service would then send a notification to a specific server ( or list of servers),
with the information it collects. It can act as a buffer, so you dont have to send a notification to the server every time you get notified internally.
I would let the service call a web service on a server, when its ready to spill its beans.
Every application you create after that should be able to check if your "crash handler" is running and notify it whenever appropriate about errors or exceptions etc.
However since this behavior will probably trip some local firewall programs, and users might question what data is being sent and when, you will want to document this well, and be very upfront with what data you are collecting, why you are collecting it, and where it is being sent.
Okay I've spent the afternoon researching and haven't had much luck finding the answer to this. I am trying to prevent an application from launching via some sort of dll or background application. It is to be used in monitoring application usage and licenses at my institution. I have found leads here regarding WqlEventQuery and also FileSystemWatcher. Neither of these solutions appear to work for me because:
With WqlEventQuery I was only able to handle an event after the process was created. Using notepad as a test, notepad was visible and accessible to me before my logic closed it. I attempted to Suspend/Resume the thread (I know this is unsafe but I was testing/playing) but this just hung the window until my logic finished.
With FileSystemWatcher I was not able to get any events from launching a .exe, only creating, renaming and deleting files.
The goal here is to not let the application launch at all unless my logic allows it to launch. Is this possible? The next best solution I came up with was forcing some type of modal dialog which does not allow the user to interact with anything, once the dialog is closed the application is killed. My concern here is killing the application nicely and handling applications with high overhead when they load such as Photoshop or something. This would also interfere with a feature I was hoping to have where the user could enter a queue until a license is available. Is this my best route? Any other suggestions?
Thanks
edit: To clarify this is not a virus or anything malicious. It's not about preventing access to a blacklist or allowing access through a whitelist. The idea is to check a database on a case by case basis for certain applications and see if there is a license available for use. If there is, let the app launch, if not display a dialog letting the user know. We also will use this for monitoring and keeping track if we have enough licenses to meet demand, etc. An example of one of these apps is SPSS which have very expensive licenses but a very limited pool of people using it.
Could you use
System.Diagnostics.Process.GetProcessesByName
in a loop to look for the process?
It might work if you don't use too aggressive a polling rate.
You are indeed close, take a look at the WMI Management Events. http://msdn.microsoft.com/en-us/library/ms186151%28VS.80%29.aspx
Sample code from Microsoft: http://msdn.microsoft.com/en-us/library/ms257355(VS.80).aspx
Subscribing to the appropriate event will provide your application with the appropriate information to perform what you described.
Not sure if this is a GOOD solution but you could do something like pass a key into main so that if the key is not present or valid the application shuts down. Then when you open the application in your code, just pass the key in. Someone would then have to know the key in order to start the application.
This is assuming you have access to the application in question's source code, which upon reading your question again, I'm not so sure of.
I assume you don't have source for the application you want to prevent from loading...
Have you considered using a system policy? That would be the best-supported way to prevent a user from launching a program.
You could have a service running that force-kills any app that isn't "whitelisted", but I can't say how well that would work.
I wonder if you are taking the wrong approach. Back in the day there was a Mac app that would prevent access to the desktop and had buttons to launch a set list of applications.
IDEA
What if you had a wrapper for the approved apps then only allow your wrapper to run on the computer?
I would expect there is some way of hooking an application launch, but can't help directly on that front.
You may be able to improve your current approach by detecting the application's window opening and hiding it (move it offscreen) so that the user can't attempt to interact with it while you are trying to shut it down.
However, another approach that may be possible (depending on your circumstances) would be to write an application launcher. This simply is a replacement for the shortcut to the application that checks your licencing conditions, and then does a Process.Start to launch the real .exe at that point. This would work well for any application. (I used a system like this for starting up applications with specialised environment settings and it works beautifully)
You could combine this with your current approach as a fall-back for "clever" users who manage to circumvent your launcher.
If my understanding is right you want to create an application what will prevent the computer user to start any other process except ones for a white-list.
If this is the case, monitor the process list of processes (in a while loop) using System.Diagnostics.Process (the GetProcesses method gives the list of all running ones)
Just kill the process when it starts.
Or if your machines have Windows 7 (Windows 2008??) you can use AppLocker. http://www.microsoft.com/windows/enterprise/products/windows-7/features.aspx#applocker Just let Windows prevent the startup.
You might want to look at this product: http://www.sassafras.com/licensing.html Personally I can't stand it, but that's because it does what you describe. Might save you some coding.
You could actually edit the registry so when you click a psd, your launcher gets called instead of photoshop. Your launcher then checks for licenses and if there is one starts photoshop with the path of the file.
This is a long shot but you may find it helpful.
Perceived Types and Application Registration
http://msdn.microsoft.com/en-us/library/cc144150(VS.85).aspx