I would think that it is dying very early in the scan process - usually a VST scanning crash indicates a bridging issue, where for some reason one or more of the 32-bit plugins are failing during the scan's query of each plugin - as it asks each plugin to basically identify itself and to supply some basic info back to the VST Scan utility.
You could try temporarily copying off the current list of search paths (so you know what to restore later, potentially), and create a new folder that you can make be the only path searched, and very slowly copy a small number of plugins from the original paths into this new folder, and slowly work your way through adding a couple of plugins at a time into that folder and then scanning, and if it works then add a few more plugins and scan again, and repeat this until you get to one that is failing, and leave that one OUT of that folder and keep on working through the rest of the plugins.
At the end of the above process, you will have a folder that contains only those plugins that do NOT crash the VST scan, and more importantly, you will have identified all of the plugins that DO crash the scan process.
Then, you can take those identified as failing OUT of the original scan paths, and recreate the original search paths for the scan, and it should now work, because any that caused the failures are no longer present in your search paths.
If it wasn't 3:30+ in the morning, I could likely have greatly simplified the comments above, and made it easier to follow. Hopefully, you will make sense of what I tried to explain.
It may be possible that there are perhaps new and improved versions of whichever plugin(s) fail, OR that there may be 64-bit versions of those plugins available, where you could end up with working versions of these plugins to complete your ending up with a complete set of plugins that work in 64-bit operation.
Bob Bone