Configuration of RSTP to stop my network frequently Dying.

Spanning tree is fairly simple to implement in terms of overall topology but preventing certain activity in the network depends entirely on your overall network implementation.

From the basic information given so far, you seems to have top down topology.  Here are few ideas to get you started at addressing this.  Beyond this, it would be helpful to post your text configuration (remove the password lines) and your network topology diagram.

1. If you have basic downstream implementation as most network, enforce specific rules to prevent root changes which has much larger negative impact.  Change the top switch to lower Bridge priority value.  Default is 32768 or 16384.  Make one the GSM at top be 0 and other 16384

2. Since you are using multiple VLAN, I will make a assumption here and ask that you make sure to use MSTP here when possible for now if the switch offers this option, otherwise stick with RSTP setting.  By default MSTP configuration is just like RSTP since there is only 1 instance running tied to all the VLANs.  

3. If the issues is someone is creating a loop, there are few things you can do to help isolate them.  If you running into broadcast flood affecting the network, then I suggest taking a basic action on broadcast control under "Storm control" under security.    Implement a more strict broadcast setting then default.  If given a choice of PPS or %, choose PPS on edge port (user port) and limit it to 100 pps/sec.  For the uplink ports on switch which connect switches together, stick with % but limit it to 1-2% at most.  Your topology is flat based on what was stated, so consider segmenting the network further if possible.   This change has a negative impact on users which will get port shutdown so make sure to implement some kind of trap SNMP server to get alerts of ports being shut down.  If you have spare virtual machine or server, install NMS200 which is free for 200 devices and spend a day or two configure it for alerts, monitoring, and notification.

4. Each of model depending of datasheet has specific features to address certain behavior dealing with BPDU.  I could elaborate those, but I suggest posting the 2 items I suggest before we start a discussion on those.  

5. Any port that is edge (meaning expected to have users’ desktop connected) should be set to   "spanning-tree edgeport"

6. To debug spanning tree quickly, when the issue occurs, connect via serial to one of top switches,  enable debug for spanning-tree bpdu via command

debug spanning-tree bpdu

You can now look at debug level buffer logging (you may need to enable that as well.  "logging console 7" to see any output.  Should give you more useful insight into what is going on instead of you flying blind.  Make sure undo the debug after you are done fixing it.

"no debug spanning-tree"

7. Quickly dealing with flooding.  There are few ways to do it.  Here are some example
8. Review the broadcast rate on the port.  If needed, clear the stats on the port, and check them quickly.  You can identify the source ports with most in order to track down to the next uplink and all the way to source port quickly to find the culprit.
9. It bit harder so I am not going to explain how to do it but how mostimplement it, using pcap to understand the culprit. Implement a port at the top level switch which will act as your eyes on the network.  Most people set aside a spare port to act as monitor destination on their top switch and typically set the source to uplink port going to the firewall or edge router.  Useful to snoop traffic going in/out of network to determine bad activity if needed. Snoop the traffic and determine the possible endpoint and track the endpoint across the network port map.

Hope this is helpful, I apologize for spelling mistakes.