Well,
the actual scenario described below will probably put the problem in proper perspective: (Note: This is not an exhaustive description of the system. Some details, unrelated to this
discussion have been omitted. Also this system is a retrofit to an already existing system.
Please ignore inconsistencies in components numbering)

The microcontroller (uP) inputs:

1. Two push button switches coming from two far off (different) locations
2. Two Door open switches from two doors ( these switches are very near to uP)
3. Two Control signals coming from some other systems

Outputs:
1. Switch ON /Blink two lamps, Lamp1 and Lamp2, depending on input conditions.
Lamps are located far away
2. Send pulses (of different widths, using LINE_SIGNAL, depending on message to be conveyed) to another system - Central Data collector system (CDCS- which will collect information from a number of such uPs and handover to PC on a LAN.

PC software pops up messages on user screens. CDCS is much more sophisticated. It is based on a Rabbit microprocessor with Ethernet Interface and has logic to detect if uP has not been communicating and will inform the same to PC)

uP does the following work:

1.Monitor Door switches and send a Pulse to CDCS
2.Monitor Pushbutton switches and send a pulse to CDCS
3.Monitor Control signals and send a pulse to CDCS
4.Periodically check if Lamps are OK or not ( continuity exists or not) and
send a Pulse to PC if required
5. Turn ON continuously or Blink the Lamps depending on combination of inputs

Problem:
There was no problem in checking Lamp status using LCHECK, L1SENSE and L2SENSE signals
There was no problem in monitoring Door switches ( proper debounce included)
These are expected to be very rare events
There was no problem in monitoring Push button switches ( proper debounce included).
This is a common event.
This is used to generate RESET to uP. This was not really necessary,
but, thought of including this as extra protection, just in case
uP hangs up. Now, by hindsight, Watchdog Reset would have been better!

There was no problem in monitoring COntrol signals

But when Lamp was turned oN ( and Only when Lamp was turned ON) monoshot used to get trigerred and a RESET used to get generated and then sometimes RESET used to get triggered again and again. So if I could avoid this extra RESET getting triggered, the problem would be solved. By avoiding ringing ( as mentioned in Erik's reply) and then monitoring S1INPUT and S2INPUT (since these are also available at port Pins) to make sure reset occured due to Push button switch only and not due to any other noise signal, my problem would be solved. RESET occurring due to any other event is of no consequence. It can be simply ignored.

So uP software has been modified to hold CLR line of monoshot to inhibit it's input for a
certain duration. With this subsequent resets are avoided. After validating that the reset
was due to pushbutton switch, action is taken. Monoshot input inhibition is removed
after a certain timeout

True, in this design , noise is not really removed. Also all protection is not present.
But I am not very much concerned, as cross verifying that push button switch pressing is done which positively identifies pushbutton switch pressing.
I shall use all the precautions that you people have mentioned in the next revised version of the same hardware, which is going to be of volume requirement.
For the present pilot run,I feel what is done now is OK

Now my only worry is about Hardware failing. Is there any possibility of monoshot failing due to external induced voltages?

System is up and running now, in actual user location (for a pilot run)
- no problem reported after so many days of very heavy usage



KG