Windows crashes on doing sql dump 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:


Through workbench
Through command prompt using mysql command
Through command prompt using mysql -h command
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:


 mysql-5.5.44
 mysql-5.5.33.2
 mysql-5.5.44.0


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
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.