Heidi crashes on Windows 10 x64 build 17134 - Access violation

jbeitler posted 9 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 8 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 8 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 6 months ago

Ditto

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

1 attachment(s):
ansgar posted 6 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 5 months 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 5 months 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.

lemon_juice posted 4 months ago

I've used Heidi a bit more in the last couple of days and I can say it still crashes like hell. Even without SSH connections. Crashes were at random events like finishing a long running query, returning an old connection after a timeout, editing a table column type, finishing a backup process and others that I can't remember now. Every 3 or 4 minutes I had a crash while working with Heidi.

ansgar posted 4 months ago

To reduce the number of crashes, I highly recommend to set a keep alive timeout of let's say 20 seconds, in the session manager on the "Advanced" tab. There was a bug in HeidiSQL which set the default value for that keep alive setting to "0", meaning "do not send keep-alive pings". I just fixed that, but previously created connections still have a "0" here.

lieszkol posted 4 months ago

That's great advice, thanks Ansgar! And thanks for all the work on Heidi. Sort of speaking against myself but if you ever took it commercial I'd definitely be a customer!

robicbl posted 4 months ago

Still having this problem. As much as I love the product (I really do!) when it's working, I have to find something else.

Ningishzidda posted 3 months ago

Hello! Sorry for the English, but I'm using a translator. I've used Heidi a lot, and I've also been constantly running into execution errors. I adopted the keep-alive strategy and got back to work, but I noticed that every time I access a field from any form using the TAB key, I get an error. When I leave a field too, but not necessarily with the TAB key. The action of entering or exiting a field would only generate some kind of error if there was some type of data checking or validation. Perhaps the problem with mistakes and falls result from this. It's a guess.

ansgar posted 3 months ago

Are you sure you are using the latest build? There were quite a few bugfixes recently for access violations.

Ningishzidda posted 3 months ago

Are you sure you are using the latest build? There were quite a few bugfixes recently for access violations.

Thx for reply. I'm downloaded latest build and yes! Bug fix :)

aSystemOverload posted 3 months ago

I've been using Heidi for sometime, on Win10 and regularly have Access Violation Crashes. If I CONTINUE, the query tab I was using is frozen, so I can't close Heidi Down and have to End Task. It is very frustrating, but despite the frequent crashes, I've found heidi to be one of the best SQL Clients in layout and functionality/usability. Just wish it had the Dashboard Graphs you get in Workbench.

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