MPLAB 8.xx was notorious for crashing while opening due to a corrupted workspace file auto-loading.
Yes, I am well experienced with that behavior. Usually, one of 2 things happens: 1) It just freezes, and after a short timeout, a message that MPLab has stopped responding appears. I close and reopen. 2) It just crashes or freezes, and I need to go the CTRL/Alt/Delete route. Close it and then reopen from a normal screen. After either of those occurrences, MPLab seemed to work normally. This is my first time with the incurable, except by cold reboot, message that the application is still running.
I suspected it might be something in the current project's workspace, so I opened a presumably good previous project and got the same results. Just tried again, and got the same crazy behavior.
I appreciate your suggestions and link and will try them later. Right now, I want to finish a working draft of a new routine and will tolerate that behavior, but it is definitely frustrating. I should get back to repairing it over the weekend.
As an aside, I Usually use the 16F1829 for development of routines. It seems robust and allows 3 hardware breakpoints. On another project I switched to the PIC16F1789 for more pins that allowed easier routing. That worked fine, until it didn't. I started getting an ICD 3 programmer error that the chip returned a wrong ID. After 2 months with very slow responses from Microchip and trying lots of things that didn't work, I changed the .jam file to an earlier version. Worked great, until very recently (September, 2023). I suspect ICD 3 automatically updated and will have to try that fix again. BTW, there is an error in the .inc file for that chip that prevents assembly. One of the SPI registers is misnamed. That fix was easy. All I did was add a define making wrong name = correct name.