MUSHclient hangs when rebooting on Windows 7

Hi guys, scoured the forum but I either didn't see or must've missed the solution to this particular problem. I'm using MUSHclient 4.43. It installs fine, and works great, until I reboot my computer. Then I get "MUSHClient has stopped working", along with the standard 'end program' and 'pretend to do something useful without providing any further information and end the program anyways' options that Windows 7 gives when a program crashes. Here's the only information that it gives me, hopefully it'll tell you guys something:

Problem signature:
Problem Event Name: APPCRASH
Application Name: MUSHclient.exe
Application Version: 4.0.43.0
Application Timestamp: 4a7f3ac4
Fault Module Name: MUSHclient.exe
Fault Module Version: 4.0.43.0
Fault Module Timestamp: 4a7f3ac4
Exception Code: c0000005
Exception Offset: 001c1bcc
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: f2e0
Additional Information 2: f2e0538414a1a64cd792a0c0c11b374a
Additional Information 3: a9f4
Additional Information 4: a9f447d9122ab619c152b05438606ff4

So, anyone have any ideas? I'd like to not have to reinstall the program every time I reboot my computer.

Side-note: Running it as admin with no compatibility(compatibility doesn't change anything, I tried 'em all).

Do you reboot the computer with MUSHclient running? If not, it sounds like some remnant has been left over (can't imagine what). If so, then maybe it doesn't notice the "reboot" message, and just sits there.

I had similar issues with Win7 in my first install of it, but never had the second one of them. Never with MUSHclient in specific, though, but many applications would crash at shutdown time.

The reason I spotted is that all of these programs pop up a 'have you saved', 'do you really want to close the program' kind of popup. Windows 7 might not actually show those windows due to the black fade covering most things, or they might be otherwise obscured. If there's no input after X amount of seconds, Windows has to conclude the process crashed since it isn't abiding by the mandated close message.

Try deselecting all checkmarks on the Global Configuration screen, Closing tab.

PS: This is all guesswork, be it with a good foundation.

Hey guys, I think I figured out what the issue was. In order to save in the default directories in the Program Files folder, I had it set to run with admin privileges(because, for some reason, Win7 defaults to not allowing the user access to change files in the program folders). I changed the security settings to allow me access to change the files, turned off admin privileges, and it works again. Haven't rebooted yet, but I'm going to do that now and I'll post again in a minute.

Also, no, I close all programs before rebooting/shutting down the PC. Helps avoid unnecessary junk hanging around.

Yeah, that was the problem. Security for the MUSHClient install folder was set to read-only on the user level, and it was running with admin privilege so it could write to the Program Files folder. So, changing the security for the install folder and all subfolders to allow read/write on the user level, and turning off admin solved the problem.

For Vista and 7, I highly recommend you either install MUSHclient somewhere other than Program Files or make your own custom shortcut that sets the target directory to something you are allowed to write permissions.

Using the elevated admin permissions and/or changing security for folders are not optimal solutions, since you're circumventing the measures Microsoft put into place for you.

I'd love to know why World of Warcraft doesn't seem to have this issue. Its addons are also kept in its Program Files folder, if I recall correctly.

I am guessing the Blizzard installer changes folder permissions. The MUSHclient installer doesn't muck around with permissions.

It does, if I recall. Either way, changing the permissions or installing the client to another folder resolved the issue entirely. Hopefully this will help other people having similar issues. :)

Out of curiosity, could I ask why not? It seems like it would quite easily solve the issues with MUSHclient in Program Files, but I don't know the cons of it.

Twisol:

An installer isn't supposed to muck around with the permissions of the program files folder. All that needs doing is that Nick properly seperates the binary and static data from the settings and other user generated data so it isn't an issue.

I think WoW simply does it because rewriting and restructuring the entire client is far too much work and relatively 'dangerous' with such a big program that earns so much money. In comparison, on a business perspective, changing some permissions is far safer.

That is assuming WoW doesn't correctly save the user data stuff in the place it is supposed to - Application Data. Not Program Files.

Laziness?

Somehow, delving into the documentation for the installer, and then for each successive version of Windows, and then making, and testing, an installer that works for Windows 98 upwards, and somehow (if possible) still works for people that use thumb drives, and maybe plug them into Windows XP and home and Windows 7 at work (or some other combination) just makes me feel very tired.

And then this improved installer has to preferably not fiddle with the Registry (for people who want to keep their playing of MUD games at work a secret), but also cope with how they currently have it installed, without lots of errors about missing world files, or missing plugins, or log directories not found. It sounds like a big task to me.

Duly noted.

It would be changing the permissions of its own folder, not Program Files itself. I see no inherent problem with the former, though clearly the latter is undesirable.