Slony-I service filling up my event viewer in Windows - windows

I wrote a similar question before but I got no answers so I was thinking on asking again in a simpler way.
I have slony-I replicating databases in a windows environment (Master has windows xp and slave has windows 7, both with postgreSQL 8.2). I registered a service using slon -regservice in both master and slave and everything works fine.
The problem I have is that the service is writing logs in the event viewer every time it runs so I have 5 or 6 new logs every second. I was hoping that it would write only errors in the event viewer but it writes logs all the time and the event viewer in my master server is getting filled with them. Since windows xp has a limit of space in the event viewer, the logs make the event viewer reach its limit and all the applications that use the event viewer crash.
Is there a way to configure the slony service to avoid writing logs in the event viewer?
Any help will be greatly appreciated. I've been struggling with this problem for 2 weeks now and I read every tutorial in the web and all of them have the same instructions but none of them mentions the logs in the event viewer. Am I missing something?
Thanks!

You probably ought to raise a bug in the Slony-I bug database or e-mail their mailing list. Since it is open source you could even re-build it and remove the unwanted event logging. Also, you don't need to register to receive event logs but you probably want errors.
You appear to be using Windows XP which is rather decrepit now – it's 10 years old! The modern versions of Windows have much more resilient event logs.
Finally, you could reconfigure the event log settings to try to avoid the problem. You could make the log much bigger (512KB default is quite small) and there appear to be other settings available. Open the event viewer, right click one of the event logs and select properties.

Related

How to activate / enable the process notification feature in API Monitor?

API Monitor has a feature to automatically watch for a new process starting and ask if you want to monitor it. However I have not been able to get this to actually work. The only option in the program I can find which seems to be related is the File menu "Pause Process Notifications" option. However, this is disabled which gives me the impressions that it can't be turned off but also that it is supposed to work automatically "out of the box". But whenever I start a new process, nothing happens.
Specifically I'm referring to the feature described here:
Process Notification
API Monitor intercepts process creation and allows you to select the
process for monitoring. Each time a process is created by the system,
a notification window is displayed with options to monitor, skip or
terminate the process. This is especially useful for monitoring
processes with a short lifespan or processes that are automatically
launched in the background. Process Notification can also be used to
monitor applications such as consent.exe (UAC prompt), which run on a
different desktop.
The following screenshot shows an example of the Process Notification
window that is displayed when launching an application that requires
elevation
I've tried both the 32-bit and 64-bit versions of API Monitor (Version 2.0 Alpha-r13) running both as regular user and as admin; makes no difference.
How can this feature be activated?
The specific reason I'd like to use this feature is that I have process A which starts process B, and it is B I need to monitor. A and B each run for only a few seconds so I can't manually get it to monitor fast enough.
Finally after reading through API Monitor forums I found some information. Unfortunately (for now at least) it seems the answer is that this feature no longer works (since Windows 8.1).
As posted on http://www.rohitab.com/discuss/topic/40418-process-notification-on-81/?p=10093378
rohitabPosted 11 October 2013 - 03:38 AM
Due to security related changes in Windows 8.1, the Process
Notifications feature of API Monitor does not work. I will try to
resolve this issue as soon as possible and post a hotfix.
But a later update in 2014 indicated that it hadn't been fixed yet, and seems not to have been since then either.
It was implied that running in a Windows 7 (or 8.0?) virtual machine might be a workaround, or obviously finding another tool which has this capability.

Is there a way to re-direct Windows crash reports to the application developer?

I apologize but I don't know the official name of the system I'm referring to, here is a screen shot showing the dialogs (note: Don't confuse "Shell" w/ Windows Shell, in this case "Shell" is the name of the my process that is crashing):
Two questions:
What is the name of the system/technology shown in the screen shot? Not the application that is crashing, but the system that is handling the crash, collecting the dump file and sending it.
If I have an application that for some reason I can't handle or catch all exceptions for, is there a way to redirect the sending of the crash data to a recipient I specify? Or register a handler or something? For example, if it were my application crashing and the user clicks the ''Send information'' button can I send that info to my email address or some other endpoint?
Most of your question has already been answered by #HansPassant:
That is the WER dialog, the crash activated Windows Error Reporting. A component written by Microsoft, it sends crash info to a server in Redmond. Microsoft uses it to fix the kind of bugs that they can fix. But most likely in your case it is your bug, they won't fix it. But you can get the info that WER gathered about it by following these guidelines.
Note that you need a code signing certificate to complete the registration and you need a few extra steps to identify your application. You'll only get small dumps (< ~1 MB), which sometimes don't help (often don't help for .NET).
#HansPassant also pointed out how to handle a crash yourself:
Or you create your own service, that must get started with SetUnhandledExceptionFilter() so you get the crash info before WER does.
However, there are a few more options to get the dump:
there is a Registry key called LocalDumps, which you can use to save dumps on a local disk. Please consider turning that on only if you need it, otherwise it'll easily fill your customer's hard disk. This works very fine if the crash is reproducible at the customer's site but not on your machine.
use a free library like CrashRpt (open source; please check the license) or Doctor Dump. This perhaps has the disadvantage that you need to set up a server to collect the data.
see more options which I described in the answer How do I take a good crash dump for .NET, which also works well for native applications.

Application error: fault address 0x00012afb (Expert)

I need some "light" to get a solution. Probably there are tons of things that cause this problem, but maybe somebody could help me.
Scenario: a Windows server running 24/7 a PostgreSQL database and others server applications (for processing tasks on database, etc...). There are differents servers scenarios (~30), with different hardware and windows versions (XP SP3/ WinServer, etc... all NT based). All aplications were written in Delphi7, and link to DLLs (in D7 also).
After some days (sometimes a week, sometimes a couple of months), Windows begins to act strange, like not opening start menu, some buttons are missing in dialogs. And soon some applications do not open, raising a event on eventviewer:
Faulting application x, version y, faulting module kernel32.dll, version 5.1.2600.5781, fault address 0x00012afb
In mean while, others applications open fine, like notepad, iexplore, etc... but SOME of my applications don't, with only event log described above. But if we do not restart system, in a few days even cmd.exe stops open, (and all other applications) with same error on eventlog.
I've tried to find 'what' can cause this, but with no sucess. So, and any advice will be welcome.
Thanks in advance.
I think you are running out of resource handles (Window handles). You can verify this by having a look at the system properties in Sysinternals Process Explorer (a better task manager). I think even the default task manager can help out to display a handle count. Then you can identify which application is causing the trouble.
Once you know the application leaking and if it is yours, you can use Rational purify or Boundschecker to drill down to the problem. If you do not have money for these tools you will have to reduce the problem manually a bit by deactivating some features for example and see if the handle count still increases...
Not sure if it is the problem you are experiencing maybe it is completely unrelated. But easy to check. The track is that some app is stealing some global resources as you experience trouble with other applications. Applications like notepad do not use much resources so appear to work fine, heavy apps are more likely to show up the trouble.
Hope it helps.

Detect/Redirect core dumps (when a software crashes) on Windows

For my work, I need to create a service that will detect an abnormal program termination and, instead of displaying a message to the user (default behavior), send the generated core dump to a remote server.
I'm pretty sure this can be done, but I have absolutely no clue on where to start. Is there any API/registry settings for this ?
Thank you.
One method is to install an Unhandled Exception Filter and then write a minidump from it which you can then upload to some place of your choosing. I wouldn't totally disregard Windows Error Reporting -- that's an addition to any crash reporting of your own. If your application is for public release then registering for Windows Error Reporting is well worthwhile as you get information about which crashes users are encountering in the wild and when crashes have been fixed you can add a response code to point them to a new version or other relevant information.
Another tool that may be useful depending on how your application is deployed in your organisation is to run Adplus on a user's machine which will collect together crash dumps. This is more useful for one-off crashes that seem to affect an individual user but aren't reproducible in a development environment.
Some other useful links:
http://www.debuginfo.com/articles/effminidumps.html - some useful sample code
http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
It seems my question was either obvious or stupid (both ?) but anyway, i found some interesting pages after some researches.
Here are the links I found useful:
Track application crashes and disable Windows Error Reporting at the same time!
Disable error reporting

Retain Windows Error Reporting Dumps from Hung Application

An application is hanging occasionally, and I would like to see the dump at the time to figure it out. I had written an application that the user can run to automatically create a dump that I can look at. However I can't seem to get the users to remember to run it when it hangs, no matter what I try. They always end up closing the program, which invokes Windows Error Reporting.
WER will create dumps in the temp directory, but unfortunately they are deleted as soon as the dialog for sending the info to Microsoft or not is closed.
Becoming an ISV and getting this info from Microsoft's error reporting servers is one solution.. but not one that is realistic at the moment.
I can't imagine that I am the only one faced with this issue. The software is used concurrently by dozens upon dozens of staff, so reaching them all and getting them to run an application or not click close on that dialog until running some other application or etc has not been working out.
The app is running on Windows Server 2003. Too bad, since I know Server 2008 has some LocalDumps options that will let me retain them.
Any ideas for somehow keeping these dumps around so I can analyze them? The obstacle is the user, in the sense that I've accepted to their stubbornness and do not expect them to run any other application or do anything special.
Thanks for any advice!
You could opt for an automatic solution. I believe there're multiple options at your disposal for detecting if you're hung.
One would be the use of SendMessageTimeout (also pay attention to SMTO_ABORTIFHUNG as one of the fuFlags values) from a separate thread in your app. Once you have determined the main thread is not responding you can save a dump file wherever you want.
There's also a IsHungAppWindow() (user32.dll) available since w2k.

Resources