[fixed] r4001, Win7-64: Fails with ZwGetContextThread!ntdll (null)(0) +18

[tomreyn]

Thanks, are these logs of actual crashes, though?

Edit: Yes, these are crashes, great.

Can you please also let us know whether you have all the latest Windows service packs and single update patches (including all the optional ones which fix bugs) installed? I'm not sure we discussed this, yet.

[tomreyn]

No need to respond to my question since I was just able to reproduce this on a fully patched Windows 7 Home Premium 64 bit in a VirtualBox VM on a Ubuntu 12.10 x86_64 host, using MegaGlest r4065. I started the Anarchy scenario, sent workers to dig gold, produced more workers, and had one build barracks. Then I did something else entirely for a good while (probably 20 minutes) and when I got back to look at the VM I saw the message on screen. I was still able to mark players and issue commands in the background (and the game generally continued), but after confirming the message the game exited with the known error message.

So it seems like yesterdays' guess can be correct and this is actually a Windows 64-bit specific bug (I was unable to reproduce it on a fully updated Windows 7 32-bit box the other day, using a very similar setup). Looks like the 5 hours I spent on getting a usable Windows installation was kind of worth it in the end.

Code: [Select]

[2013-01-29 17:50:50] *ERROR* Unknown C++ exception thrown.6079641|Unknown module|Unknown function
6138797|Unknown module|Unknown function
6139126|Unknown module|Unknown function
6139376|Unknown module|Unknown function
11935763|Unknown module|Unknown function
11711607|Unknown module|Unkno [Unknown error [main]!
Stack Trace:
00000000 00000000 00000000 2f7f0cec ZwGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 2f7f0cec ZwGetContextThread!ntdll (null)(0) +18
]
It would also be good to ensure that the snapshot build box (valkyrie) is not the source of this issue, since, if I recall things correctly, the 3.7.1 release is not affected. Can you please confirm, Nig or Frost?

[nig]

Im using win 7  64 pro Sp1 on the laptop and Win7 64 Home premium  Sp1 on the desktop

Both are actual patched with "important updates"

both are having the described issues.

Congrates to your installation. Be Happy that its not Win8. They say this takes two weeks.

After your question I had a deeper look at system config again.

Using this tool: http://www.realtech-vr.com/glview/ i found, that there seem to be serious driver issues with nvidia drivers on Win 7 64 with open GL

Have a look at that. May be you find something. I am fumbling around here too.
May be you know another tool to check open GL-Functions?

Greets

[Omega]

Using this tool: http://www.realtech-vr.com/glview/ i found, that there seem to be serious driver issues with nvidia drivers on Win 7 64 with open GL

So it seems like yesterdays' guess can be correct and this is actually a Windows 64-bit specific bug (I was unable to reproduce it on a fully updated Windows 7 32-bit box the other day, using a very similar setup). Looks like the 5 hours I spent on getting a usable Windows installation was kind of worth it in the end.

Strange, I'm unable to produce it myself. I played a ~25 minute successful game. I did encounter an unrelated issue that I'll describe later, but I couldn't find the issue here (I'm also using Windows 7 64 bit with Nvidia drivers, namely the latest drivers for the GTX 560 Ti. Open GL is at its latest version. Windows is completely up to date. Granted, I'm running 3.7.1, not the latest rev. I'm just not sure if it's Win 7 64 bit in general that's affected. I'm going to grab the nightly build and see if I can reproduce.

EDIT: Tested with rev 4065, still no errors.

Nope, now it comes up. Started the game up and let it sit for an hour. Didn't do anything at all, and not sure how long it took, but the dialogue box appeared. Clicking okay crashed the engine.

[nig]

Using this tool: http://www.realtech-vr.com/glview/ i found, that there seem to be serious driver issues with nvidia drivers on Win 7 64 with open GL

to be precise, on the laptop I cannot get a positiv rendering test for open GL 3.0, 3.1.

everything blow is okay, 3.2 and 3.3 seems to work.  Dont know, if that means anything.

Greets

[Coldfusionstorm]

Now since im following this thread i just had to say this.

Will you stop that anti-windows hate? , it's getting REALLY old. I have windows have run windows for a long time, If it takes 5 hours installing you are doing something wrong okay?, Windows is not!, Windows 7 is especialy effective at installing and you can have it installed in 20 minutes. and then 10 exstra for drivers for perheriphals like USB-headsets, Okay, So will you PLEASE s... up?, Do you hear me whine over how many problems ive had with linux do you KNOW how many hours ive wasted trying to get linux to work with simple games?. No.

(sorry for the off-topic but this anti-windows hate have gone long enough).

[nig]

cool it baby. to get a samba file share working on fedora took me three weeks.
to get a second display working on nvidia cpu on suse takes two hours.
there is crap everywhere, if you are able to face the truth.

Greets

[tomreyn]

Using this tool: http://www.realtech-vr.com/glview/ i found, that there seem to be serious driver issues with nvidia drivers on Win 7 64 with open GL

to be precise, on the laptop I cannot get a positiv rendering test for open GL 3.0, 3.1.

everything blow is okay, 3.2 and 3.3 seems to work.  Dont know, if that means anything.

I was actually unable to test this utility myself since it wouldn't work in my VM at all, it does not even start up there. So while this can be due to the pass-trhough from Linux I'm not sure about this utilities' quality either, so please don't spend too much time on it. It was just an attempt to work around the failing --opengl-info and get your video info nevertheless. Another tool you can try is GPU-Z. It's small, and widely used, but it doesn't really provide OpenGL specific otput so it's not that useful for our needs. But it can provide you with a better idea on the overall stability of your drivers.

To me the message this thread is about is more likely not video driver or vendor specific, though, since, if I recall correctly, we have reports from all of Nvidia, ATI, Intel users who have encountered this message so far. So something else seems to be there, something 64-bit specific.

To confirm, it would be good to know whether any of you who have run into this ZwGetContextThread!ntdll message

• is running a 32 bit Windows version
• has ever compiled the game yourself on your Windows 64 bit variants post v3.7.1
• has had the message come up with a development build you compiled yourself (in contrary to the ready-made development builds you can download)  on your Windows 64 bit variants post v3.7.1

[nig]

well, win XP32 SP3, Geforce 6200 is running in an error too when looking at "Anarchy" on dev 4060. But the error-message is slightly different:



3.7.1. shows no error on this machine.

Compiling on Win 7 64 seem to be nothing for noobs and the wiki seem to need a little update.

The link to Visual c++ 2008 Express is broken - and this one is not supporting WIN7 anyway, sais Microsoft. Jam is needing Visual c++ too.

Googling for Visual c++ Express running on Win7 64 shows up Visual c++ 2010 and: lots of "well known issues using c++ on 64 Bit Machines"

Pointers are always 64Bit, but some systemvariables are remaining in 32 Bit and conversion is done by truncating, if you do not program your own workaround, i read.

Seem to be too complicated for me little windowsgamer...sorry

Greets

[tomreyn]

Compiling on Win 7 64 seem to be nothing for noobs and the wiki seem to need a little update.

The link to Visual c++ 2008 Express is broken - and this one is not supporting WIN7 anyway, sais Microsoft. Jam is needing Visual c++ too.

Hmm, where are you reading this (please post the URL so we can update it)? We use VC++ 2010 and haven't been using jam for the past 2(?) years. The current development section on the wiki says you need to use VC++ 2010.

Googling for Visual c++ Express running on Win7 64 shows up Visual c++ 2010 and: lots of "well known issues using c++ on 64 Bit Machines"

Pointers are always 64Bit, but some systemvariables are remaining in 32 Bit and conversion is done by truncating, if you do not program your own workaround, i read.

Seem to be too complicated for me little windowsgamer...sorry

I just built on Windows 7 64 bit (using the 32 bit compiler as per default) as documented on the Wiki. It worked fine and without any problems.

Using this build, I've been running the Anarchy scenario for 20 minutes without an issue now.

Update:
... and it did crash now, too (just had to wait a little longer):

Code: [Select]

[2013-01-30 13:27:17] *ERROR* Unknown C++ exception thrown.6078633|Unknown modul
e|Unknown function
6137789|Unknown module|Unknown function
6138118|Unknown module|Unknown function
6138368|Unknown module|Unknown function
11936147|Unknown module|Unknown function
11711991|Unknown module|Unkno [Unknown error [main]!
Stack Trace:
00000000 00000000 00000000 f04cd99b ZwGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 f04cd99b ZwGetContextThread!ntdll (null)(0) +18
]
R6025
- pure virtual function call

[nig]

huh?

i was fooled by the link in the megaglest-bugreport board right under the search, which lead me to the glest wiki : https://docs.megaglest.org/Compiling
instead to the megaglest-wiki https://docs.megaglest.org/MG/Windows_Compiling where i belong to.

sorry for complaining ... still afraid ...

Greets

[tomreyn]

Those links (forum announcements) are forum wide, the wiki is a shared resource, but has sctions specific to the games. I can see how this can be irritating (which is why we discussed having a separate wiki for MegaGlest a while ago). The easiest way to access the MegaGlest specific part of the shared 'Glest wiki' is by http://wiki.megaglest.org/.

About compiling yourself: this would have been good to rule ou the possibility that the supposed bug is related to the configuration of the development snapshot build system. However, since we now have proven that this issue also occurs when you build on a freshly configured Windows 7 64-bit box I think we ruled this possibility out. And thus there is no strict need for you to setup a build system, too.

Instead, let's concentrate on making this issue easily and reliably reproducible. The more we can break it down to a simple test the easier it will be for testing whether a fix has been found. So what we need is a reliable way (works every time you do the procedure), and one which can be achieved easily (simple setup, no or little manual intervention) and fast (short test time). You already worked in this direction, maybe we can make it even easier?

Everyone who is running into this issue, which I assume is everyone running MegaGlest on Windows 64-bit, is welcome to help with this.

[softcoder]

I had a person from the debian games team try to reproduce this on windows 8 64 bit and windows 7 64 bit and he could not (using details from this posting). He even additionally compiled megaglest and ran in debug mode to see if the error would show a stacktrace but he never got any errors. This makes me think that perhaps not everyone will get this bug.

*Update: I've finally got a real errror handler working and should be able to get you something soon that will give a full stack trace in windows. I'm going to add support for google-breakpad which will allow users to submit a dmp file for any crash and we will be able to get a stack trace on our end from that. This works on Linux, Mac and Windows

[softcoder]

Ok anyone who is able to reproduce this on Windows, try the binary here:

http://soft-haus.com/glest/temp/megaglest-win32-3.7.2-dev.7z

When it crashes, it will show a messagegox indicating the path and filename of the crash dump. Post the link here in the forums to your dmp files so i can check out the problem.

Thanks

[Omega]

Erm, I ran the program and let it run in the background. About twenty five minutes in, MegaGlest crashed and the executable closed without warning (no error message, nothing). I checked the log files in the user directory and none of them were changed (except glest.log, which is just the loading stuff).

[nig]

D:\372dev>megaglest.exe
megaglest.exe v3.7.2-dev
Compiled using: VC++: 1600 on: Jan 30 2013 09:53:25 platform: Windows endianness
: little
SVN: [$Rev: 3951 $] - using STREFLOP [SSE] - [no-denormals]
AL lib: ReleaseALC: 1 device not closed

D:\372dev>

thats all it sais

[edit:] debug and network are written as told in ini: http://www.datafilehost.com/download-ffd2eb0d.html

[tomreyn]

Ok anyone who is able to reproduce this on Windows, try the binary here:

Thanks for your work on this. This binary is built from r3951, which is (or is close to) the 3.7.1 release revision. My understanding, based on reading this and the other forums threads on the topic, is that this supposed bug is either only or at least much easier reproducible with current development builds (I was able to reproduce it on r4066). Could you make a test build against a current revision available, too?

[titi]

After more than a year I started up my windows again. I can establish and reproduce all the things nig reported:
what I did:

3.7.1: no problems
3.7.2-dev  ( latest binary from nightly build ): crash as reported by nig
3.7.2-dev from softcoder posted above ( same result as nig )

update: I forgot my specs:
gfx nvidia 450m
system win7 64bit

[tomreyn]

D:\372dev>megaglest.exe
megaglest.exe v3.7.2-dev
Compiled using: VC++: 1600 on: Jan 30 2013 09:53:25 platform: Windows endianness
: little
SVN: [$Rev: 3951 $] - using STREFLOP [SSE] - [no-denormals]
AL lib: ReleaseALC: 1 device not closed

D:\372dev>

thats all it sais

Was the error actually reproducible this time? Please always state this even when you post log files. I had a glance at your logs and my guess is there was no crash, no fatal error, i.e. you were unable to reproduce.

[tomreyn]

Now I reproduced it on r4069 (my own build, produced on the same system) on my Windows 7-64 VM using the setup Nig described in an earlier post on this topic.

I'll repeat the steps to reproduce:

1. Start a custom game using the following setup (this is based on Nig's screenshot posted earlier in this thread):

Code: (lastCustomGameSettings.mgg) [Select]

Description=Four Rivers
MapFilterIndex=0
Map=four_rivers
Tileset=winter_forest
TechTree=megapack
DefaultUnits=1
DefaultResources=1
DefaultVictoryConditions=1
FogOfWar=1
AdvancedIndex=0
AllowObservers=1
FlagTypes1=0
EnableObserverModeAtEndGame=1
AiAcceptSwitchTeamPercentChance=30
FallbackCpuMultiplier=5
PathFinderType=0
EnableServerControlledAI=1
NetworkFramePeriod=20
NetworkPauseGameForLaggedClients=0
FactionThisFactionIndex=0
FactionCount=4
FactionControlForIndex0=7
ResourceMultiplierIndex0=5
FactionTeamForIndex0=8
FactionStartLocationForIndex0=0
FactionTypeNameForIndex0=*Observer*
FactionPlayerNameForIndex0=tomr_w7_64
FactionControlForIndex1=2
ResourceMultiplierIndex1=4
FactionTeamForIndex1=1
FactionStartLocationForIndex1=1
FactionTypeNameForIndex1=magic
FactionPlayerNameForIndex1=AI1
FactionControlForIndex2=2
ResourceMultiplierIndex2=4
FactionTeamForIndex2=2
FactionStartLocationForIndex2=2
FactionTypeNameForIndex2=tech
FactionPlayerNameForIndex2=AI2
FactionControlForIndex3=2
ResourceMultiplierIndex3=4
FactionTeamForIndex3=3
FactionStartLocationForIndex3=3
FactionTypeNameForIndex3=magic
FactionPlayerNameForIndex3=AI3
FactionControlForIndex4=0
ResourceMultiplierIndex4=10
FactionTeamForIndex4=0
FactionStartLocationForIndex4=4
FactionTypeNameForIndex4=persian
FactionPlayerNameForIndex4=Closed
FactionControlForIndex5=0
ResourceMultiplierIndex5=10
FactionTeamForIndex5=0
FactionStartLocationForIndex5=5
FactionTypeNameForIndex5=romans
FactionPlayerNameForIndex5=Closed
FactionControlForIndex6=0
ResourceMultiplierIndex6=10
FactionTeamForIndex6=0
FactionStartLocationForIndex6=6
FactionTypeNameForIndex6=tech
FactionPlayerNameForIndex6=Closed
FactionControlForIndex7=0
ResourceMultiplierIndex7=10
FactionTeamForIndex7=0
FactionStartLocationForIndex7=7
FactionTypeNameForIndex7=*Random*
FactionPlayerNameForIndex7=Closed

2. Position the camera on top of the green or blue base. Keeping the camera on the start position or positioning it on top of the yellow base will not trigger this bug.

3. Press + as often as desired to increase game speed.

4. Watching the mini map you can observe that the bottom left Tech CPU (green) attacks the top left Magic CPU (yellow) and while only few troops persist undefeated, these destroy Magic's main building (don't move the camera to verify). Now the top right Magic CPU (blue) also attacks the top left magic CPU (yellow), and overruns them. The following error occurs during this attack (08:37 game time on the second day), where a battlemage of the top right (blue) CPU attacks the top left (yellow) CPU's last remaining summoner guild, and before the summoner guild is destroyed. An error message is displayed in a messgae window on screen, and is also written to the cmd.exe console error stream.

Further notes, reproduced from what Nig already reported:
Storing, then restoring a savegame does not allow for reproducing this bug.
The screen resolution setting does not matter.

Code: (Error message) [Select]

megaglest_r4069.exe v3.7.2-dev
Compiled using: VC++: 1600 on: Jan 31 2013 15:57:05 platform: Windows endianness: little
SVN: [Rev: 4069M] - using STREFLOP [SSE] - [no-denormals]
Error saved to logfile [C:\Users\user1\AppData\Roaming\megaglest\error.log]
R6025
- pure virtual function call
[2013-01-31 16:23:30] *ERROR* In [..\..\source\glest_game\main\main.cpp::Glest::Game::ExceptionHandler::handleRuntimeError Line: 578] [Unknown error [main]!] gameInitialized = 1, program = 029E87C8
[2013-01-31 16:23:31] *ERROR* In [..\..\source\glest_game\main\main.cpp::Glest::Game::ExceptionHandler::handleRuntimeError Line: 597] [Unknown error [main]!
Stack Trace:
00000000 00000000 00000000 9d258483 ZwGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 9d258483 ZwGetContextThread!ntdll (null)(0) +18
]
[2013-01-31 16:23:41] *ERROR* Unknown C++ exception thrown.6078665|Unknown module|Unknown function
6137821|Unknown module|Unknown function
6138150|Unknown module|Unknown function
6138400|Unknown module|Unknown function
11936211|Unknown module|Unknown function
11712055|Unknown module|Unkno [Unknown error [main]!
Stack Trace:
00000000 00000000 00000000 9d258483 ZwGetContextThread!ntdll (null)(0) +18
00000000 00000000 00000000 9d258483 ZwGetContextThread!ntdll (null)(0) +18
]

[softcoder]

Not 100% sure but this Bug seems to be making it hard to track this in windows 7 64 bit, it talks of a hotfix

http://support.microsoft.com/kb/976038

[tomreyn]

Erm, I ran the program and let it run in the background. About twenty five minutes in, MegaGlest crashed and the executable closed without warning (no error message, nothing). I checked the log files in the user directory and none of them were changed (except glest.log, which is just the loading stuff).

I assume "the program" refers to the build softcoder provides at http://soft-haus.com/glest/temp/megaglest-win32-3.7.2-dev.7z (which uses code from Google breakpad). Now I've also tried this build twice, and reproduced the bug in the custom game setup Nig had described (and I repeated above). Both times the game screen (and process) vanished, but there was no output on screen, and nothing written to standard output and error streams at all about what went wrong there. The only thing you get is the output the game prints when starting up.

[titi]

I tested a lot now and it turned out that this error is really nasty ...
It does not happen always for me but most of the time.

The best way to trigger this bug is setting up a custom game as nig said:


Then start the game and exit it.
Now from the commandline start the game with

Code: [Select]

megaglest.exe --autostart-lastgame
Speed up the game using speedloops set to 8 and wait ....
the second time blue starts to attack yellow it should crash.

My current state of testing:
I was able to reproduce this crash with 3.7.0 3.71 and many svn revisions from 3.7.2-dev
I was not able to reproduce this bug with 3.6.0.3

[nig]

after a complete reinstall ( Ihad big issues ( inclusive instant crashes connecting to headless), which seem to relate to cache directory) I had a game on headless with 4077 on headless with leandro. Debug and logging was off. leandro was leaving early because of being found by overmighty cpu.

I played a little longer and everthing was fine. I didnt play to end because i had no chance against 3,9 Mega CPU. I quit the game.
I quit megaglest complete by pressing the "return" button and everything close nicely.

after all I saw this:



surprise, surpise! There is the promised dumpfile, but the Zwget did not appear...

dumpfile : http://www.datafilehost.com/download-d08907e4.html

Greets

[edit: may be leandro did not quit, but was thrown by unreported error? Headless was german Linux 3.7.1.]

[edit2: After that I let run "Anarchy" on Speedloops=2 again. Megaglest collapses at the well known time completely. No error Message, no dumpfile, no nothing. just closed]

[tomreyn]

Some log from yesterday's IRC chat on the matter:

<tomreyn> bug reproduced on r3988
<tomreyn> r3964 also has the bug
<tomreyn> i'll try the 3.7.1 release
<softcoder> ok but nig says 3.7.1 works
<tomreyn> well, dunno, maybe it slipped
<tomreyn> crashed
<tomreyn> that's r3948

I also said this, but I'm no longer sure this can be relied on, I may have made a mistake:

<tomreyn> r3801 (=v3.6.0.3) is next
<tomreyn> reproduced on r3801

And more chat from today:

<titi_linux> I have no bugs in 3.6.0.3!
<tomreyn> really? you tried to reproduce it there?
<titi_linux> yes several times
<titi_linux> I used the "official" binary
<titi_linux> I tried it about 10 times
<titi_linux> I never crashed there
<tomreyn> did you use the installer?
<tomreyn> or the separate packages
<titi_linux> seperate package
<titi_linux> just the binary with current data
<titi_linux> and xerces.dll from this package

During this test, Titi was using the 3.6.0.3 binary, but game data from 3.7.1 release.

Later today:

<tomreyn> first i'll try reproducing it on 3.6.0.3 again. i'm using separately downloaded data and binary packages from sf.net
<tomreyn> it turns out 3.6.0.3 plays the game differently
<tomreyn> blue dies first, not yellow

So this is a useless test case, unless you mix and mojo binaries, game data and INI settings like Titi did.