Heidi crashes on Windows 10 x64 build 17134 - Access violation

jbeitler posted 5 months ago in General

Please assist. I think Heidi has a lot to offer but can't use it because it constantly crashes.

This is a new install.

date/time : 2018-06-18, 14:35:11, 37ms

computer name :

user name :

registered owner : temp / Microsoft

operating system : Windows 10 x64 build 17134

system language : English

system up time : 3 days

program up time : 16 seconds

processors : 4x Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz

physical memory : 1707/8049 MB (free/total)

free disk space : (C:) 197.44 GB

display mode : 2560x1600, 32 bit

process id : $77cc

allocated memory : 92.42 MB

largest free block : 131025.96 GB

executable : heidisql.exe

exec. date/time : 2018-06-18 14:18

version : 9.5.0.5278

compiled with : Delphi XE5

madExcept version : 4.0.12

callstack crc : $b97fef7e, $39af944f, $39af944f

exception number : 1

exception class : EAccessViolation

exception message : Access violation at address 0000000000865097 in module 'heidisql.exe'. Write of address 0000000000000058.

main thread ($9334): 00865097 heidisql.exe SynTextDrawer 924 +7 InitETODist 008652d7 heidisql.exe SynTextDrawer 974 +1 TSynTextDrawer.ExtTextOut 0088c29a heidisql.exe SynEdit 3975 +66 PaintToken 0088cca2 heidisql.exe SynEdit 4131 +63 PaintHighlightToken 0088f4fd heidisql.exe SynEdit 4624 +215 PaintLines 0088f8ed heidisql.exe SynEdit 4694 +53 TCustomSynEdit.PaintTextLines 00887b4c heidisql.exe SynEdit 2906 +61 TCustomSynEdit.Paint 006a6856 heidisql.exe Vcl.Controls TCustomControl.PaintWindow 0069d603 heidisql.exe Vcl.Controls TWinControl.PaintHandler 006a408d heidisql.exe Vcl.Controls TWinControl.WMPrintClient 0040d90e heidisql.exe System TObject.Dispatch 00695ca3 heidisql.exe Vcl.Controls TControl.WndProc 0069d36e heidisql.exe Vcl.Controls TWinControl.WndProc 0089c5a6 heidisql.exe SynEdit 8581 +22 TCustomSynEdit.WndProc 00695780 heidisql.exe Vcl.Controls TControl.Perform 0069e553 heidisql.exe Vcl.Controls TWinControl.WMPaint 006a67e8 heidisql.exe Vcl.Controls TCustomControl.WMPaint 008988a8 heidisql.exe SynEdit 7370 +16 TCustomSynEdit.WMPaint 0040d90e heidisql.exe System TObject.Dispatch 00695ca3 heidisql.exe Vcl.Controls TControl.WndProc 0069d36e heidisql.exe Vcl.Controls TWinControl.WndProc 0089c5a6 heidisql.exe SynEdit 8581 +22 TCustomSynEdit.WndProc 0069c5aa heidisql.exe Vcl.Controls TWinControl.MainWndProc 005dce43 heidisql.exe System.Classes StdWndProc 7ffb94be ntdll.dll KiUserCallbackDispatcher 7ffb93f6 USER32.dll PeekMessageW 008156bc heidisql.exe Vcl.Forms TApplication.ProcessMessage 00815833 heidisql.exe Vcl.Forms TApplication.HandleMessage 00815d1f heidisql.exe Vcl.Forms TApplication.Run 00cd4877 heidisql.exe heidisql 80 +24 initialization 7ffb9482 KERNEL32.DLL BaseThreadInitThunk 7ffb94bc ntdll.dll RtlUserThreadStart

lieszkol posted 4 months ago

I would like to second this. Heidi crashes once a day at least, and when it does I can't even recover what's in the editor. Super, super frustrating. It regularly happens when Heidi loses the connection and tries to reconnect in the background.

I'm not familiar with Delphi, but surely there must be some way to catch these exceptions and handle them without crashing the whole program. Or are these bugs coming from SynEdit and thus simply unavoidable? Could perhaps each window be run in a separate process, with a separate SynEdit instance, so that if SynEdit crashes in one of the editor windows it doesn't take all of the others down with it? Maybe it's a silly idea I'm just trying to think of ways to mitigate this. Why does losing the DB connection lead to the component in charge of syntax highlighting to crash, could these two aspects of the software be decoupled somehow?

If there is no hope for mitigation OK, let us know, and I'll bite the bullet and use some other editor, but the thing is I really like HeidiSQL (I've also donated my share). It has a great UI, I like the fact that each tab isn't using it's own DB connection, and it's so intuitive to use.

In any case thank you for all the work you put into Heidi.

1 attachment(s):
lemon_juice posted 4 months ago

I agree. Crashes are too common in Heidi and this makes me switch to other programs for most of database tasks. Heidi is a superb tool but the crashes are making it unusable sometimes.

I've submitted a few crash reports in the past as have other users but unfortunately Ansgar said he can't do anything about them because they are caused by some underlying platform or library that he has no control of. So I'm afraid that after all these years we may have to accept the crashes are here to stay forever...

The most frustrating ones are when I have multiple query tabs open and suddenly Heidi crashes when doing anything - there seems to be no repeatable pattern when they occur. And after restarting all my tabs with queries are lost, even no trace of them in query history. And sometimes Heidi just closes itself without warning when switching tabs or doing some other stuff and again, all queries lost upon restart.

At least a partial solution would be to implement some tab restore feature so that after restarting I can recover the queries. And every query should be saved to query history on disk immediately after pressing F9 just before running it.

To me this problems is big enough to warrant switching to another library/platform/language/whatever, because the otherwise wonderful application is ruined by the constant crashes. But that is probably only what we may hope for, for I understand how much work it would entail and Ansgar may simply not have enough time for this.

dhagwood posted 2 months ago

Ditto

Just installed. Can't work more than five minutes without crashing.

1 attachment(s):
ansgar posted 2 months ago

I just committed some fixes for two of the above reported issues. Please update to the next nightly build and report back if that changes something for you.

lieszkol posted 1 month ago

Thank you Ansgar for keeping at this issue, I will install and check. I wanted to reply to this thread for a few weeks now. Quick synopsis: after trying many others, Heidi is still my favorite MySQL editor, and it turns out most of my crashes were due to trying to connect via SSH tunnel using Heidi. By instead setting up port forwarding with Putty, I was able to eliminate most Heidi crashes.


After my last post 3 months ago I made the plunge to try and move to another MySQL client. I tried (in order of preference):

  • DBForge Studio for Mysql (pretty good but somewhat slow and complicated to use)
  • Navicat for MySQL: this is a nice alternative BUT for whatever reason if you run a script and there's an error in it, you simply aren't notified...you can look through the output log but unlike Heidi, the output isn't color-coded so it's difficult to realize there was an error in your code, also, each open tab is tied to its own db connection unlike with Heidi
  • SqlYog: much like Navicat, it isn't obvious if there was an error in the script you just executed
  • JetBrains DataGrip: subscription-based, and I refuse to go down that road (I can imagine myself with $200+ /month subscription fees on software), also just waaaay overcomplicated and sloooow with big scripts
  • DBeaver: OK but very basic tool
  • TeamSQL: not at all suited for sql projects where you store version-controlled source files on local machine And a few others that aren't worth a mention.

My conclusion? Heidi is simply the most intuitive, fastest tool for working with MySQL. Some aspects of Heidi that I just love - and can't fathom why the $$$ alternatives are unable to incorporate into their products:

  • Shared connection between tabs. If I want to run 10 scripts on my dev/test db, and, if things went OK, run it on production, then I just first choose my dev db, run the scripts in order, and then choose my production db, and repeat. So simple! Many other tools maintain one connection per open tab. This way you have to keep switching.
  • Speed. Several "competing" tools are written in Java, heck, some are written in JavaScript. This is OK for small scripts, but as soon as you try to work with larger scripts, or many open tabs, some of these tools just become plain unusable. Not Heidi!
  • Showing the user if something went wrong in your script! Basic, right? And yet many of the alternatives just have an "output" window that isn't even color-coded. You are left to look through it to make sure none of your statements produced a warning/error.
  • Enough features, but not too many: some of these competing tools just are really an overkill. The number of useless features just gets in the way.

Somewhere down the line I realized that the reason Heidi was always crashing for me was because I was always opening connections via an ssh tunnel set in Heidi. Whenever the comms broke down, Heidi would try to recreate the connection and crash. I've been able to use Heidi with 95% of the crashes eliminated by creating an ssh tunnel in Putty. So I connect to my servers using Putty first (check out mRemoteNG!), and then use Heidi to connect to localhost (127.0.0.1). If I need to connect to several servers at the same time, I just specify different port forwarding options in Putty. So, production db is forwarded from local port 3306, dev from 3307, test from 3308 etc.

lemon_juice posted 2 weeks ago

lieszkol, each of the tools you mentioned has its pros and cons. I'd love to find one piece of database software that satisfies all my needs but that seems like an impossible requirement. Heidi has an advantage of being small (in terms of installation), can be portable, is fast like a native Windows app and pretty easy to learn and use with a nice UI.

As to other software you mentioned, these are my observations:

  • Navicat - I tried it some time ago but it's UI and feature set was missing as compared to Heidi - this was surprising to me for paid software. I can't remember the specifics but I dumped it very quickly.
  • SqlYog - I don't know what is your problem with the errors - when I run a script in SqlYog and there is an error I get notified about it immediately in the Messages tab. However, I don't use SqlYog often, its main advantage to me is its dump database feature - it is reliable, fast and allows me to select objects to dump. Contrary to Heidi, I get a nice progress indicator during the dump and the UI does not lock up. The paid version has some more nice features but I never needed them.
  • DataGrip - I haven't tried but it's not only subscription based - if you subscribe for 1 year then you get perpetual licence for that version, so in effect it's like reserving cash for software equalling 1 year's subscription and then the software is yours forever - but without upgrades, of course.
  • DBeaver - I use it often I wouldn't call it very basic, in fact I find it one of the most feature rich tools. But it's made to work with many different database systems so it may not have all the features needed to administer a database. I prefer Heidi for administering databases and altering tables. However, for data viewing and editing DBeaver is superior in almost all respects and does not crash. And it also offers automatic ER Diagram generation, which is very useful for complex schemata.

I don't know if my past crashes in Heidi were due to SSH, I think I got crashes also in connections without SSH. Unfortunately, I can't tell if the recent fixes improved the situation because now I most often manage data with DBeaver so I use Heidi less often. Also, I use Postgres more often so Heidi is not a good option with only very basic support.

Please login to leave a reply, or register at first.