Zugg Software :: View topic

Wizard Joined: 14 Oct 2000 Posts: 1368

This is a really odd bug because it seems to just happen a bit now and then. Especially when I use multiple accounts in Windows this seem to happen.

1. Start zMUD.
2. Splash screen is shown, "Initializing ...".
3. The message box "Access violation at address 74E20B09. Read of address 74E20B09." is shown. I click OK.
4. Same message as above is shown again. I click OK.
5. Windows error handling window is shown. I have to press Debug or the window is just shown again.

Notes about the error:
I have 3 accounts in Windows. An admin account, an user account which I use to play games or develop some smaller stuff with, and a development account where I try to only do programming.

As my current project is to attempt to make a MUD-server I access zMUD from both the user account and the development account. As I need to use clean settings while developing I have installed zMUD into two different folders. One for the gaming account, and one for the development account.

Now if I do this after Windows starts I get the access violation mentioned above:
1. Start Windows.
2. Login to Gaming account.
3. Login to Development account.
4. Start zMUD in development account ---> access violation.

Only way to now start zMUD seems to be to logout from all the accounts and then login to Development account first.

System specifications: Windows XP Home Edition

Newbie Joined: 20 Jun 2005 Posts: 1

I'm having the exact same problem...but so far have been unable to fix it.

Any ideas??

Wizard Joined: 14 Oct 2000 Posts: 1368

Rynor is it version 7.13a you are using? Just to make sure it really is the same issue as there was a similar one in version 7.13 (without the 'a').

Posted: Mon Jun 20, 2005 5:12 pm

1) Rorso, let me try to understand this: If you log into Gaming and then Development, zMUD fails. If you log into Development directly (without logging into Gaming), then zMUD works?

2) Are you using the Fast User Switch in XP, or are you logging out of Gaming and then logging into Development normally?

3) I assume that you installed zMUD and ran it the first time using the Admin account?

4) After logging into Gaming and then Development (when zMUD fails), have you tried right-clicking on the ZMUD.EXE and selecting Unlicense from the eLicense Control menu. Then try to run zMUD and see if you get the Trial/License screen?

5) Go into your Registry, and in the HKEY_CURRENT_USER/Software/Zuggsoft area, delete the zMUD keys where the plugin information is stored just to be sure it's not trying to load any plugins. Also delete the ZMUD.INI file to remove any plugin info in there.

6) Do you have zMapper installed and licensed? If so, try running zMapper to make sure it's license is working properly. You might also try unlicensing and re-licensing that.

The reason I am asking all of these things is that zMUD is trying to do several things at the point in which it crashes for you. It is loading plugins, including the zMapper plugin. eLicense is partially involved in that. My guess is that eLicense is fine, though, because zMUD itself is getting past the normal eLicense startup.

The other thing it's trying to do at that point is to load your character database, but if the SQLITE.DLL is in your zMUD directory, I'm not sure how that can fail. You can always try renaming your CHARDB.DB file and let zMUD create a new one, but I doubt that's the problem.

Also, I don't know what special wierd stuff Microsoft does when switching between accounts like that. If you give me the exact procedure you are using to switch accounts I can try reproducing it here.

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Tue Jun 21, 2005 5:17 pm

a) Does this only happen when using the Fasts User Switch? In other words, if you log out of the Gamer account first, and then log into the Dev account, do you still get the error?

b) I'm not sure what you mean by "you might have to delete some files...". What files are you deleting exactly? Why are they becoming read-only? zMUD certainly doesn't set any files to read-only.

I'll try to reproduce your procedure on my system here, but it won't be until this weekend when I've gotten the zApp White Paper and CD shipped off to the publishers.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

b) they become "read only" because they were created using the administrator account, meaning that a user account (with less permissions) cannot modify them since they belong to someone with higher permissions...

Posted: Wed Jun 22, 2005 4:19 pm

Hmm, ok. Is there a way I can change the installer so that this doesn't happen? Seems like some apps ask a question about whether the program should be "installed for all users" and if I can figure out how that works, maybe I can improve it.

Rorso, I'd check *all* of the files in your zMUD directory. If there are access privileges getting in the way, then it's possible that one of your files, like the database files or even the sqlite.dll can't be accessed after another user has installed the program. That could also explain why I can't reproduce the problem.

It might also explain why some other people have trouble if they are installing via their admin account and then trying to run it from a normal account and have certain files locked because of permission issues.

Wizard Joined: 14 Oct 2000 Posts: 1368

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

The "correct" way to do it these days is to store data in either
a) the registry in HKEY_CURRENT_USER
b) their "My Documents" directory under their username in "Documents and Settings"
c) their "Application Data" directory under their username in "Documents and Settings"

You can get the location for 'b' and 'c' at runtime from the registry keys under:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

For example on my system the key "Personal" points to "C:\Documents and Settings\Rainchild\My Documents" and the key "AppData" points to "C:\Documents and Settings\Rainchild\Application Data" ... it's probably a big pain upgrading zMUD to use a directory like that though.

.......

The only other thing I can think of is when you create those datafiles (like chardb.db) you use the security API to set that file to read/write by "Everyone" (see MSDN documentation on "SetSecurityDescriptorOwner") but it gets messy because you have to be running NTFS and probably NT/2000/XP to have the DLL's/LIB's/ability to actuall change stuff like that. Too much of a headache, I don't even want to try and comprehend that :p

Posted: Thu Jun 23, 2005 12:25 am

Rorso, you never answered one of my questions: If you don't use the Fast User Switch, does it work then? In other words, log out of one account and then log into the other.

Rainchild, yes, I know that, but I'm not going to use the registry, nor am I going to use My Documents or Application Data. I hate those directories, and besides, this needs to run the same on all versions of Windows.

Since SQLite is actually creating the database files for the first time itself, I have no idea what security settings they are using. But it's starting to sound more and more like a problem with the settings for one of those database files.

Hey Rorso, another thing you can try is when zMUD is failing, can you delete the mudlist.db and chardb.db files again and then run zMUD to recreate them? Does that work when the other user is still logged in? If Windows thinks that the files are owned by the other user, then it might not let you delete them.

Wizard Joined: 14 Oct 2000 Posts: 1368

Wizard Joined: 14 Oct 2000 Posts: 1368

Ok this seems to be really nasty. I decided to let MSVC++ handle the error and load the process into its debugger to see if I could get some stack trace to help you. The information I got there doesn't seem very useful though. First the debugger doesn't stop the process from running as it use to. Instead it continues to report access violation errors in its output window.

When I force it to break I get a stack trace that seems very corrupt. Wait now I seem to actually get a stack trace after enabling "Load DLL exports". I will email you the stack trace to zugg@zuggsoft.com in a moment as I don't want to clutter up this thread.

I could save a dump of the process too if it would be useful. Like in MSVC++ I can ask the debugger to load a .dmp file and it will show a stack trace with function names of the source application. Maybe Delphi can read those .dmp files too?

In either case as I seem to be the only one getting this error and can workaround it to use zMUD please priotize your other projects first :).

Posted: Thu Jun 23, 2005 4:14 pm

I'll take a look at the dump, but I'm not expecting much. There is a lot of anti-debug stuff in both zMUD and eLicense and most of the dump data is probably corrupted.

Thanks for the info on the various attempts to log out and log in. As I mentioned, I'll try reproducing it this weekend. If I can get it to crash here, then the chances of getting it fixed are much higher.

Posted: Thu Jun 23, 2005 6:51 pm

Woohoo! I got the error too!

Definitely seems related to non-admin accounts and fast user switching. But I've got a test setup that reproduces the error now, so hopefully I can find the problem and fix it. I think this is the bug that's been in the past few versions of zMUD and just moves around, so it would be really nice to get it fixed.

Stay tuned for more news.

Posted: Thu Jun 23, 2005 8:13 pm

OK, I think I found the problem. I've uploaded a new version of zMUD 7.13 (7.13b) to see if this fixes the problem. It seems to work on my test setup that was giving the error before.

I *do* still get an issue when I have zMUD installed in more than one place and then run a different one from the Admin account. When I then run one in the Game account, I get a Microsoft OLE error about not being able to access the OLE Registry. This seems to be an issue of having the same COM object located in two different places on your hard disk that gets Windows confused. If I go to my Admin account and run the zMUD in the Game account, then the Game account continues to work.

I don't think there is any workaround for that problem, but the original issue with the crash should now be fixed. So go download a new copy of 7.13b and let me know if it's fixed.

Posted: Thu Jun 23, 2005 8:19 pm

Oh, and in case some people care, this new 7.13b version of zMUD also has Remote Desktop support enabled. eLicense did some fixes to this and I think it's ok to use it now with zMUD.

I'll probably make a bigger announcement about this in a new post once I find out if Rorso's error has been fixed.

Posted: Fri Jun 24, 2005 7:30 am

Coolness, 7.13a crashed under my admin account but runs fine under a limited user (with fast switching), just updated to 7.13b and zmud runs under admin account with no access violations or wierd messing around.

Wizard Joined: 14 Oct 2000 Posts: 1368

It seems to be working now Very Happy

! Thanks for fixing it Zugg! It seemed like a very tough bug to track down. Really odd that it could make the Windows crash handler get into an infinite-loop of crashing.