You can disable the popups using the system api SetErrorMode(). You can access that api using Win32::API or via tye's Win32API::File.

use Win32API::File qw[ SetErrorMode :SEM_ ];;
print SetErrorMode( SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX );;
[download]

See the documentation for an explanation of the constants and other possibilities.

As implied in the CB, no matter how good you think your "recovery processes" may be in the production environment, I think it verges on idiocy errrr hiding your head in the sand to try to suppress what amounts to a warning that there's something seriously wrong.

Corion 2006-12-06 11:06:39-05 I'd avoid Win32::Process and use system("start $that_process");. Of course you then lose control over the launched process.

tye offered another; and I may have missed a few folk who shared wisdom. I may also be missing the point/validity of your concern that the popups may go unanswered. My recommendation would be to monitor the production environment until I you found out what's borked.

So, please, tell us WHY you're not more interested in WHY Perl is crashing. Perhaps that info will help us respond more usefully (or (?) acceptably (?)

¹Title changed -- new title lifted from a later remark-of-great-wisdom,-insight-and-frustration in the CB.

Perl Crash!?!?

¥peace from CaMelRyder¥

There is the concept of "Defensive Programming" that you really need to think about here. Why are your scripts cratering? What can you do to code around those conditions? Why aren't you?! Shooting the Messenger is very short sighted....

That said, If it were I in this pickle, I'd start by analyzing the kinds of 'Perl crashes' that cause the flower-box to appear and see if there is a common thread that I can check for. Ideally, you will discover something that you can set a %SIG trap for, and bail out gracefully once you receive the signal. This will require changes in the scripts you are running under the service.

A more heavy weight solution is to install a Monitor Program (I am very fond of Nagios) and have it check your problem-children's metrics (say CPU time consumed, memory foot-print, and log-file size). If the appropriate metric stabilizes for too long (and that's a judgment decision you have to make), have the Monitor kill() the process.

I really can't over-emphasize how dumb/dangerous the idea of disabling the pop-up on crash is.

Consider the following scenario (names changed for obvious reasons):

• The SysOP: Jon, According to my logs, your fizbit program crashed and restarted itself last night; once every five minutes starting at 0035 until I got here at 0800.
• Jon Q. Programmer: Oh? I was getting a lot of errors from it last week, but I fixed that.
• SysOP: Oh, really? and how did you do that?
• JQP: Simple, I redirected the logs to /dev/null
• SysOP: So what happened last night?
• JQP: I don't know, I'll have to check the logs and get back to you. By the way, where is my fizbit Report? Shouldn't it be printed by now?
• SysOP: ....

I really can't over-emphasize how dumb/dangerous the idea of disabling the pop-up on crash is.

Actually, not. It is a common and normal thing to do for applications that are intended for unattended operations.

Disabling the popup simply removes the requirement for operator intervention when such errors occur. It does not however, stop the error being logged to the Application event log.

Which, for the deliberately induced error perl -e"'x' x 1e10", records the following event log message:

Event Type:    Error
Event Source:    Application Error
Event Category:    None
Event ID:    1000
Date:        2006-12-06
Time:        17:58:57
User:        N/A
Computer:    XXXXXXXXX
Description:
Faulting application perl.exe, version 5.8.6.811, faulting module perl
+58.dll, version 5.8.6.811, fault address 0x0008775c.

For more information, see Help and Support Center at http://go.microso
+ft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 70 65 72   ure  per
0018: 6c 2e 65 78 65 20 35 2e   l.exe 5.
0020: 38 2e 36 2e 38 31 31 20   8.6.811 
0028: 69 6e 20 70 65 72 6c 35   in perl5
0030: 38 2e 64 6c 6c 20 35 2e   8.dll 5.
0038: 38 2e 36 2e 38 31 31 20   8.6.811 
0040: 61 74 20 6f 66 66 73 65   at offse
0048: 74 20 30 30 30 38 37 37   t 000877
0050: 35 63 0d 0a               5c..
[download]

Further, if you have core dumping enabled, disabling the popup doesn't stop the coredump being created.

It's simply not necessary to use a third party monitoring tool for this.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Thank you BrowserUK. In one of my posts I talked about this running as a service, but I guess I didn't provide enough detailed information as to what that really means so it was unclear to others. This is a very complex system that has been running successfully for over 4 years. It would have taken a couple of pages of details to understand how it works so I always find it difficult when I ask what I think is a simple question and get a lecture on how to write code (something I have been doing for over 25 years). I truly appreciate posts from individuals like you who answer the question that is ask.. I believe I know how to handle this situation Thanks Again

"This environment has been running for almost 4 years and we haven't had a problem until now and it's on a single server that we brought online"

So,
(1)Your problem may be with the new "single server"
and
(2)You can't fall back to what used to work just fine
and
(3) you see it as better to have a possibly buggy server causing your business to be invisibly MISSING data (which might, IMO, lead to "bad business decisions") than to take that sucker down and see what ails it?

Re-UPDATE <important>: See BrowserUK's Re^2: Prevent Perl Command Line Interpreter Popup From Appearing On Perl Crash, infra (way below, in fact.)

If that is indeed the case, then you might try to redirect STDOUT and/or (more likely to help) STDERR to a log file.

open STDERR, ">>logfile.log"
[download]

See what happens when you do

perl -e"$x = 'x' x 1e11"
[download]

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Nothing. Not even if I change the "1e11" into "1e15".

Are your machines effectively identical (i.e. similar hardware, built in the same way software wise)? This sounds a bit like flaky hardware (probably RAM, maybe CPU/cooling) to me. Any chance you can run some diagnostics (memtest86) or, better, swap out the RAM or CPU or mobo with a spare?