That error is nonsequiter with regards to MySQL. This would especially be true if your Windows server crashed for reasons other than MySQL. There are ways to fix IRQL_NOT_LESS_OR_EQUAL.
However, if you are reloading a mysqldump and it is the only reason Windows crashes, you may have to accommodate Windows until you fix the IRQL_NOT_LESS_OR_EQUAL error by applying one of the following suggestions (but not both):
SUGGESTION #1 : Change the mysqldump layout
You may have to create another mysqldump using --hex-blob or --skip-extended-insert but not both. That way, MySQL will ingest data in bite-sized chunks instead of woofing down thousands of rows of data. See my answer to the post When does creating a .sql backup with mysqldump become too large? for clarification.
SUGGESTION #2 : Change the MySQL Packet size
Most people take the MySQL Packet for granted. Some mysqldump could time out if you not paying attention. mysqldump's default for max-allowed-packet in 24M. Extended inserts can benefit from a larger packet upon reload. It could possibly increase the number of rows per extended INSERT command. Since a mysqldump can trigger a crash, you could experiment with slightly larger values (the max size is 1G). The MySQL Packet never starts out at max_allowed_packet. The size starts out at net_buffer_length and expands to max_allowed_packet on demand.
EPILOGUE
These two suggestions is really no more than a BandAid for your scenario. You need to do your homework and fix the IRQL_NOT_LESS_OR_EQUAL first before resorting to workarounds.
