MySQL Bugs: #69781: MySQL Workbench crashes; Windows 7 Enterprise 64 Bit System

Bug #69781	MySQL Workbench crashes; Windows 7 Enterprise 64 Bit System
Submitted:	18 Jul 2013 15:09	Modified:	29 Aug 2013 15:59
Reporter:	Ilia Koulikov	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Workbench	Severity:	S3 (Non-critical)
Version:	5.2.47 CE	OS:	Windows (7 Enterprise)
Assigned to:		CPU Architecture:	Any

Description:
I am using MySQL Workbench 5.2.47 on Windows 7 Enterprise 64 bit.

Okay; so I know this is repetitive, but I still have the bug. I have done the following:

• Re-installing and updating to newer version of workbench.
• Re-starting my computer.
• Running it in safe mode.
• Running it through the command line with –swrendering
• Installing newer version of the C++ Redistributable (but I already had the latest version installed...)
* Re-installing MySQL server, even though it was running okay using just the client.
* Updating my graphics card drivers.
* Installing the non-msi (zipped) version to an entirey different directory every time I attempted a repair or re-install.

Important to note that through it all, I've deleted the existing installation directory.

ALSO VERY IMPORTANT TO NOTE:
A: My users folder does not contain ANY folders related to MySQL AT ALL. I don't mean just the main folder, but all subfolders, including the current user's folder. This means that there are no old configuration files/histories to delete, unless they're moved somewhere else in the latest version.
B: I have no idea where the log file is located, none of the other posters seem to have the same folder structure as me. Furthermore, there is no file
called "log" or any variation thereof anywhere in my MySQL Workbench main folder. Only a bunch of seemingly unrelated python files. For this reason, using the debug argument was useless to me.
C: I do not have python installed on my machine in any form (short of whatever was installed by MySQL workbench).

I do not have the option to re-install all of my .net related items as some previous posters have suggested.

The set-up: I was running an update script which crashed my workbench and my entire computer froze. Upon re-start, the workbench would not start, and
upon every re-install thereafter, it has crashed in the same exact fashion, namely:

The first time it launches after an install, the splash screen just appears, and then vanishes.
The second time it launches after an install, I get the "MySQL workbench has stopped working" pop-up"

If used with -swrendering through the command line, I get the following message (also seen elsewhere)

Unhandled Exception: System.AccessViolationException: attempted to read or wtire protected memory.. blah blah blah.

Please fix this issue, guys. It's been around for years... this renders Workbench unusable and unfixable.

Failing that, can you at least let me know where the current version of MySQL workbench is keeping its corrupted history files so that I can delete
them and perform a truly clean re-install?

Thank you very much for your time,
- Eli

How to repeat:
Seen repeatedly in other posts: run a script, crash your workbench, be unable to start back up =)

Suggested fix:
No idea. Have tried almost everything else in other posts, short of reinstalling everything dotnet related.

Update: System restore to before the original Workbench crash happened did not solve issue.

Thank you for the report.

> Seen repeatedly in other posts: run a script, crash your workbench, be unable to start back up =)

Which script did you run?

Hi Sveta, Thank you for your quick response.

The script in question is a script that places information into a set of database tables that already exist. I am sadly unable to produce the script here because it is proprietary, but I can assure you that this script has been in use for weeks without changes, and was used several times that same day without crashing Workbench.

Thanks,
 - Eli

Any chance of an update on this issue?

I have now re-installed the C++ redistributable packages for both 32 and 64 bit systems (I have a 64 bit system, but MySQL Workbench comes in 32 bit only, so I'm not sure how that works). This did not help; workbench is still refusing to start in exactly the same fashion as before. 

Thanks
 - Eli

If it is possible, could you please give me a list of all possible locations on the hard-drive where MySQL Workbench could conceivably store history files, or caches of any sort? I want to make sure it's not an issue of corrupt data that it is trying to constantly reload.

Thanks,
 - Eli

Error when I launch from the Command Line

Attachment: error1Ed.jpg (image/jpeg, text), 149.01 KiB.

Error when I try to open .mwb file with old MySQL Workbench (5.2.37)

Attachment: error2.png (image/png, text), 313.94 KiB.

I've added a couple of screenshots above in case it makes the issue any clearer.

The first is a screenshot of the error that is output in the command line when I try to run Workbench 5.2.47 from there,

The second screenshot is the error that MySQL workbench 5.2.37 gives me when I try to build the ER model from our current .mwb file (which was built using version 5.2.46). 

Just an update on my attempts to make it work: 

Version 5.2.37 launches without crashing, is able to re-build the database schema from our existing backup scripts (the same ones that build the currently running and working .mwb, schema and databse). However, when I try to open the ER model from our existing .mwb file, it will not let me. 

This last one is potentially a moot point anyway since I can't use an older version of Workbench to update our current database anyway, without causing compliance issues (the other developers are all using 5.2.46). 

I'd like to add, as well, that there is nothing wrong with the database data itself. When accessed through the command line, and the MySQL client, I am able to view all of the tables, column information information, etc, and make changes, but, as you can imagine, it slows my workflow quite a bit.

Thank you very much for looking into this,
 - Eli

Update: I have now done a full defrag of my drive, and a system error check, a re-install, and MySQL Workbench will still not start.

May the internet laugh at me for all eternity; I was in windows 7 and I forgot to check that I could view hidden folders; Once I fixed that, I was able to access the roaming data in my users folder and delete the corrupt Workbench data. The latest version is now working on my computer. Thanks to Sveta and anyone else who looked into this.

 - Eli

* Covers face in shame...

Thank you for the feedback.

Unfortunately, it is hard to verify, then fix the bug if there is no repeatable test case (model file which causes this error). We will think which other information can we request and update the report.

Can you provide the script that you ran? If it's a built-in command, what exact command is it?

Hi Sveta and Alfredo,

I wanted to once again mention that the problem has been solved for me.

Again, I cannot reproduce the script, but it consists of about 500 lines in this format:

INSERT IGNORE INTO xxx VALUES (int, int, int, 'stringValue', passwordSeed, int, int);

- With variations according to table structure. The script itself is nothing special, and again, had worked several times that same day without change (and for months without major change previously).

The script is likely not the source of the problem; if you guys are trying to reproduce it, I would recommend dropping your schema (whatever it may be), re-building it, and re-populating its values several times as quickly as you can. I have observed on several occasions that Workbench starts acting iffy when I do that, but only once has it crashed as I describe above (and I've been using it this way for ~6 months.

Thanks,
 - Eli

So the issue is solved and not way to repeat?. Thanks.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".