Windows simply crashes and opens the blue screen for dumping physical memory on trying to import sql dump. Blue screen error: IRQL_NOT_LESS_OR_EQUAL So far I have tried 4 methods:

  1. Through workbench
  2. Through command prompt using mysql command
  3. Through command prompt using mysql -h command
  4. Through ant: ant import-database after creating data-sync folder

Windows crashes in all the 3 cases

Before each new trial I un-install mysql and delete the MySQL folder from Program Files and MySQL data from Program Data. Size of dump files is 2.75 GB.

MySQL versions I have tried with:

  1. mysql-5.5.44
  2. mysql-
  3. mysql-

System configurations:

  • Workbench: 6.3.30
  • My system has 12 GB RAM
  • Windows 7 Service Pack 1
  • AMD A6-5400B APU with Radeon(tm) HD Graphics 3.60GHz
  • Does the import succeed on a different computer? – Michael Green Jul 10 '15 at 20:47
  • 1
    Please provide your dump to the developers via bugs.mysql.com . – Rick James Jul 11 '15 at 0:36
  • @MichaelGreen: Yes the import works perfectly fine on a different computer. – Farrukh Chishti Jul 13 '15 at 9:00
  • Actually the import does not succeed entirely. It crashes a few times but then it imports anyway. – Farrukh Chishti Aug 3 '15 at 10:49
  • Tell us the exact mysqldump command you tried. Tell us which version of MYSQL and from which OS (is it from Windows or Linux?), you have taken the dump. Also tell us what exact command you used to take the dump and how big it is. – ypercubeᵀᴹ Aug 11 '15 at 10:41

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.


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.

  • SUGGESTION #2 failed completely. I tried with packets of size 33554432 and 900554432. In both the cases windows crashed. – Farrukh Chishti Aug 3 '15 at 11:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.