EQ-Client kicks without warning

Status
Not open for further replies.
Active are these, but not all are really used somehow:
Crash happened last time while in heavy fight.
Mashing buttons over 2 systems via EQBC.
Piggyzone, Posse, Reachit, MMOWarp was not in active usage.
Most went in that moment over EQBC, MQMelee, MQCast,
MQMap, MQEvents, MQTracking, MQBot, MQMoveutils.
I have searched for Logfiles but I am not even sure which
accounts crashed last night because I was so furious that
I kicked all EQ-Accounts to get a fast load with the new
MMOBugs distribution running in hope to rescue the mission
(which did not work either, fail/ld a mission, then you can
restart :().


mq2ic=1
mq2mmobugs=1
mq2advpath=1
mq2autogroup=1
mq2casttimer=1
mq2chatfilter=1
mq2chatwnd=1
mq2custombinds=1
mq2dpsadv=1
mq2eqbc=1
mq2eqbugfix=1
mq2events=1
mq2exchange=1
mq2gmcheck=1
mq2hud=1
mq2hudmove=1
mq2instancekill=1
mq2itemdisplay=1
mq2labels=1
mq2log=1
mq2map=1
mq2mmobzsrch=1
mq2mmofastmem=1
mq2mmotlo=1
mq2mmowarp=1
mq2mybuttons=1
mq2nav=1
mq2netbots=1
mq2netheal=1
mq2piggyzone=1
mq2portalsetter=1
mq2posse=1
mq2reachit=1
mq2rez=1
mq2targetinfo=1
mq2tracking=1
mq2twist=1
mq2cast=1
mq2moveutils=1
mq2melee=1
mq2bot=1

EDIT:
What did you change btw from 18th to 20th update?
Was it only luck that the system worked over 6 hours flawless with the 18th update?
The only difference from these two was the update - I didn't changed the active plugins as far as I remember.
 
Another MQ2 updated is out. There were some detours left in to last update that shouldn't have been in there. That could of been cause as different between 18th and 20th version.

Htw put some work into fixing our crash dump submission system too, so if we didn't fix it, hopefully we can get a crash dump to figure out what did.
 
Oops

I was on a vacation so I wasn't able to keep posting / testing, though it seems some of you have been super thorough. Now that I'm back and I've updated MQ2 to the latest version, I will start testing.


I know it is difficult for Fry et al though because it wasn't triggering a crash dump. The window would just close as though I hit the red "X" or right clicked on the taskbar and selected "close window."

I am running two systems, one's a laptop and the other is a desktop. Both run windows Enterprise.

I use the old school WinEq and not ISBoxer. So I don't believe it is limited to ISBoxer, and I don't use docrack.


Just tried loading and running my team. 1 out of 6 closed after a couple minutes of running. No bug report window---I didn't even notice it closed until I realized one of my boxes wasn't responding.

I should add that I'm running the same setup / macros I've been running for years--no real changes of substance except for my recent switch from using EQBC to using DanNet and recently started using EqWire.

Edit: Tad bit more info, it used to be my main that would crash (close), now it's my other boxes. It's also random as in I can't force it to happen, and there hasn't been a crash dump available as of yet.


Another Edit: It was DanNet that caused the most recent crash apparently.

[2019/01/21 21:13:54] ToonName - [MQ2] make_minidump: C:\MacroQuest2\Logs\mq2dannet_20190122_021354.1104.dmp
[2019/01/21 21:13:56] ToonName - [MQ2] Exception notification: MQ2DanNet::Node::read crashed at address 0x11D49A
Dump saved to C:\MacroQuest2\Logs\mq2dannet_20190122_021354.1104.dmp

You can click retry and hope for the best, or just click cancel to kill the process right now.
Can I attach the DMP here or should I send it to someone? Just didn't want to post something that might have character names in it...


My plugins are as follows:


Code:
[Plugins]
mq2ic=1
mq2mmobugs=1
mq2aaspend=0
mq2advbeep=0
mq2advloot=1
mq2advpacks=0
mq2advpath=0
mq2autoaccepttrades=1
mq2autoafk=0
mq2autobuff=0
mq2autoclip=0
mq2autodestroy=0
mq2autoforage=0
mq2autogroup=1
mq2autologin=1
mq2autosize=0
mq2autoskills=0
mq2bandolier=1
mq2bardswap=1
mq2bot=0
mq2botbeta=0
mq2boundtlo=0
mq2buffblock=0
mq2bzsrch=0
mq2camera=0
mq2capslock=0
mq2casttimer=0
mq2casttlp=0
mq2cecho=0
mq2charnotes=0
mq2chat=1
mq2chatevents=0
mq2chatfilter=1
mq2chatwnd=0
mq2clickies=0
mq2clickmaint=0
mq2clip=0
mq2compassutils=0
mq2cpuload=1
mq2crypto=0
mq2cursor=0
mq2custombinds=1
mq2customsound=0
mq2dannet=1
mq2debuffs=0
mq2docrack=0
mq2doors=0
mq2dps=0
mq2dpsadv=0
mq2eqbc=0
mq2eqbugfix=1
mq2eqdraw=0
mq2eqdxfix=0
mq2eqim=0
mq2eqwire=1
mq2etrack=0
mq2events=0
mq2exchange=1
mq2fakelink=0
mq2famkiller=1
mq2feedme=1
mq2filterset=1
mq2focii=0
mq2fog=0
mq2fps=1
mq2funnynames=0
mq2g15=0
mq2g19=0
mq2gamparsehelper=0
mq2gemtimer=0
mq2getmission=0
mq2gmcheck=1
mq2gzone=0
mq2headshot=0
mq2hoverinfo=0
mq2hud=1
mq2hudmove=0
mq2ifs=0
mq2instancekill=0
mq2irc=0
mq2itemdisplay=1
mq2krust=0
mq2labels=0
mq2languages=0
mq2linkdb=0
mq2log=0
mq2logoutclick=0
mq2map=1
mq2masterlooter=0
mq2mastermind=0
mq2medley=0
mq2mercmanager=0
mq2missing=0
mq2mmobzsrch=0
mq2mmodps=0
mq2mmofastmem=1
mq2mmokite=0
mq2mmomakegroups=0
mq2mmonowelcome=0
mq2mmopopup=0
mq2mmotext=0
mq2mmowarp=1
mq2mmoxp=0
mq2movementrecorder=0
mq2mybuttons=0
mq2namesay=0
mq2nav=1
mq2netbots=0
mq2netheal=0
mq2nogold=0
mq2nogoto=0
mq2nomountmodels=1
mq2nostun=0
mq2nosummon=0
mq2notify=0
mq2otd=0
mq2pccheck=0
mq2pcsafety=0
mq2piggyzone=0
mq2pluginman=0
mq2pop=0
mq2portalsetter=1
mq2raidutils=0
mq2reachit=1
mq2relaytells=0
mq2remotecamp=0
mq2removedet=0
mq2reward=0
mq2rez=1
mq2screenshot=0
mq2setrace=0
mq2shitlist=0
mq2shutdown=0
mq2size=0
mq2slotcolors=0
mq2soundcontrol=0
mq2spawnmaster=0
mq2speedutils=0
mq2spellhotkeys=0
mq2spellsearch=0
mq2spelltimer=0
mq2startmacro=0
mq2stealth=1
mq2supercast=0
mq2targetinfo=0
mq2targets=0
mq2taskaddaccept=0
mq2telnet=0
mq2timer=0
mq2timercolor=0
mq2timestamp=0
mq2tooltip=0
mq2tracking=0
mq2tributemanager=0
mq2twist=0
mq2vendors=0
mq2viewport=0
mq2vladutil=0
mq2voicecommand=0
mq2web=0
mq2wickedspeed=0
mq2winamp=0
mq2wintitle=0
mq2xptracker=0
mq2cast=1
mq2moveutils=1
mq2melee=1
 
Last edited:
If you right click mmoloader tray icon, and send debug report, if it's not the right dump file, you can click alternate dump button.


htw
 
I tested last night again with removing some plugins, esp. older ones - even they are not used or active.

This ended again with a series on crashes. The strange thing was that on BOTH systems (Win10WS, Win7Ultimate) the crashes came one after the other while in fighting. It was about 30min again. If it is one installation then the other wouldn't have been kicked at the same time. The connection between these two is going via EQBC but the same one I use always. The only differences are the updates via MMOBugs.

I sent a couple of dumps because all boxes crashed one after the other with a time delay of some seconds. I never had such a series on crashes... really nasty...

I have not much time atm to make extensive bug search with swapping DLLs and rebooting. To many plugins, too much time with 30min, to many accounts to really be able to verify this one without spending a whole day testing and rebooting.
But I can say:

- it is never the same account, they seem to crash in random
- it needs a bit time for playing
- they crash on two systems which have a connect via EQBC
- they crash in a kind of round-robin/alternating pattern, one crashes and on both systems step by step many go
- not all accounts crash, some are sometimes left
- last time 7 crashed on the Win7 and about 4-5 on the Win10
 
I tested last night again with removing some plugins, esp. older ones - even they are not used or active.

This ended again with a series on crashes. The strange thing was that on BOTH systems (Win10WS, Win7Ultimate) the crashes came one after the other while in fighting. It was about 30min again. If it is one installation then the other wouldn't have been kicked at the same time. The connection between these two is going via EQBC but the same one I use always. The only differences are the updates via MMOBugs.

I sent a couple of dumps because all boxes crashed one after the other with a time delay of some seconds. I never had such a series on crashes... really nasty...

I have not much time atm to make extensive bug search with swapping DLLs and rebooting. To many plugins, too much time with 30min, to many accounts to really be able to verify this one without spending a whole day testing and rebooting.
But I can say:

- it is never the same account, they seem to crash in random
- it needs a bit time for playing
- they crash on two systems which have a connect via EQBC
- they crash in a kind of round-robin/alternating pattern, one crashes and on both systems step by step many go
- not all accounts crash, some are sometimes left
- last time 7 crashed on the Win7 and about 4-5 on the Win10
If you could update I would appreciate it, then you can upload debug reports on crashes so I can take a look. Your loader is 1 rev behind (need update to .14, it should self update if starting with no eq sessions running). Same for your compile release, you're running .3, and latest is .6.
After the updates and when you crash just send debug reports via the interface that comes up, and I can take a look.
Thanks much.

htw
 
Sent.
A lot of crashes now. If the one system crashes, the other follows mostly instantaneous and the series follows with 2-3 crashes on the same system.
 
Sent.
A lot of crashes now. If the one system crashes, the other follows mostly instantaneous and the series follows with 2-3 crashes on the same system.
MQ2DPSAdv is showing up as your primary crash issue. Unload it for now, and send any further dumps (thanks much for sending those btw!). I am working on dpsadv.


htw
 
mh.. the new gameparse 2 beta is out. I saw that I had spikes with some named of nearly 2 Million DPS. Perhaps that plugin has problems with more than 1 Mill DPS. That would explain it.

I will test it further.

Many thanks.
 
Those couple startup ones you sent are inner space doing it.


Code:
ntdll!RtlFreeHeap+1f
779ae061 f7464400000001  test    dword ptr [esi+44h],offset InnerSpace+0x30000 (01000000)
 
I thought so. Innerspace/ISB has really bad bugs and compared to EQBC the connection between computers with heavy load is sometimes a catastrophy. It disconnects additionally after some hours regularly.

EQBC has also bugs. It sometimes adds LOGIN_ to the name and therefore no communication is possible. This happens the rarest at Emules EQBC 1.3. The other which have more text load running are partly absolutely unstable or connection wrong or are slow like hell (at 18-31 toons raids) and therefore absolute unusable at high load. Despite the EQBC bug, after EQBC quit and reconnect I get it mostly running then there is no real annoying lag (a bit sometimes) and the crew works.

I had now again a crash while login out. I assume this is Innerspace/ISB too but I cannot sent in something because MMOBugs did not catch the crash. Sadly I made the work to pull up all toons with ISB and its a load of work to reconfigurate all to another keybinder. Else I would change out ISB/Innerspace instantly. Esp. in connection with MQ2Autologin bugs are always present :(

I played now after I got the toons in for around 4 hours without problems (with deactivating MQ2DPSAdv) with the last MMOBugs patch.
 
Unreasonable kick is back after last patch.
2 accounts kicked/vanished without error message again.

To avoid problems with other installations (which are surely there), all is installed freshly on Win10Enterprise and worked for many hours until today with the updated MQ2 patch.

I only zoned into a mission and one of the 6 mission boxes vanished and at the same time another "buffstation" in another zone got kicked too which only did "nothing" then standing in the zone.

Addon:
- neither MQ2Events, nor MQ2DPSadv is loaded
- MQ2Autologin has the old bug again with skipping part of the account name after a "_", e.g. xxx_yyyy will display only xxx. That has been fixed some weeks ago. No it is back too.
 
And again.. in the middle of the mission - the next account kicked without notice. In this form MQ2 is again completely unusable, like last time. Unpredictable kicks in the middle of hardcore mobs... not good...
Whatever you changed last patch forms into a desaster at moment in game :(

Is there any option to go back to another patch version if something like this happens? I start to dare not to update anymore until somebody tested it, if I am in a critical mission.

Addon:
- now toons get kicked round-robin, one after the other every around 2-5min
 
I need a dump file. If they aren't being created in your MQ2\Logs dir (or wherever LogPath is set to in macroquest.ini), please check your file/dir ACLs and windows paging file location and size.


You could also try using procdump (should be a copy in your MQ2 dir), e.g.:
procdump -e -ma -w eqgame.exe c:\mq2\logs

htw
 
sorry... too much... I have no clue about that...
and honestly I have not much time to dig again so deep into that...
I am a customer, a user, a gamer....

and the dump does not make any sense either..

I have 9-12 EQClients running. The one which does the error is gone, so no chance to procdump something which is not present anymore (despite it complains that many tasks have that name).

Simply: I have not changed ANYTHING. But your patch changed something. I have setup exactly for that reason to be sure that it is not something interacting a pure system which worked flawless over many hours without any crash, any kick, nothing. Both systems have the same OS. I can now grant that something in the last patch (difference from last patch!) is borked which worked before and it seems it is the same like the problem in MQ2DPSAdv.

I simply need the last compile and then I can verify it. Sadly I trusted the updater. Big fault. This is the best and fastest solution as long as the bug is impossible to reproduce out of no dump at all.

I tried it today again. After around 30min - regularly every 5min about 2 toons disappear without crash, without hanging task - they simply quit.
 
Pretty sure its not mmobugs issue. Ive been getting random crashes for awhile just like you're describing and i dont use mmobugs compile. Ill log on and just sit there and sometimes the game crashes.
 
lol.. what issue should that then be. If I exchange the versions or DLLs and I can repeatingly get crashes or avoid them (or bugs) then the thing is more than clear. I am used to search for bugs, but only with the right tools (btw. it does no crash with an error message, it simply vanishes without a trace). Before 25th I had crashes from time to time and removal of MQ2DPSAdv produced a perfekt system without crashes for hours. Sorry... that is something which is definitiv and we found that out - or better HTW found it out (many thanks for that one).

At moment I make step by step exlusion method to find out who is the one causing the crash. If I would have access to the last compile from 27./28. then this would be much easier. The actual compile on the website (28th) is not stable. It must be one before it I assume.

But I can say one thing:
Going back to 25th and the xxxx_yyyy bug is gone. So that bug has been done assumingly around 27th/28th.

For the crashes and the kicks I always need to play 30min+.

Can I have access to the 27th compile somehow?
 
Status
Not open for further replies.