Before you begin, identify the “good” server. This will be the most up-to-date master server.
Now, follow the steps below.
Good Server:
Note: Tables will be locked when running this command.
| 
					 1  | 
						mysqldump --add-drop-table --master-data --quick -u root -p --all-databases > dump.sql  | 
					
Copy this file (found in the MySQL bin directory) to the same directory on the bad server.
Bad Server:
| 
					 1  | 
						stop slave;  | 
					
| 
					 1  | 
						mysql -u root -p < dump.sql  | 
					
Check that both the Slave_IO_Running and Slave_SQL_Running processes are running.
| 
					 1  | 
						show slave status\G  | 
					
They should automatically restart after the dump.sql file is imported. If this does not happen then run the following command.
| 
					 1  | 
						start slave;  | 
					
Flush and lock tables… and then check the master status.
| 
					 1 2  | 
						flush tables with read lock; show master status;  | 
					
Make a note of the File and Position values.
Good Server:
Replace the master_log_file and master_log_pos values with those recorded in the previous step and then run these commands.
| 
					 1 2 3 4  | 
						stop slave; change master to master_log_file = 'mysql-bin.000437', master_log_pos = 497028273; start slave; show slave status\G  | 
					
Check the status of the slave to ensure that replication is working.
Bad Server:
| 
					 1  | 
						unlock tables;  | 
					
The Master-Master replication has now been restarted!
To gain a general overview of the process, I found this article useful.
My method focuses on fixing Master-Master replication for an entire server (instead of just one database) running within a Windows environment.
Depending on how often replication breaks, I may write a quick PowerShell script to automate things a little.