Intertmittent MP Crash on Session End

[Panzertard]

Update #8

Not sure if this is going to be a trend, but I've had a very long day at the lovly 159'th server - and long missions.

IMO: I do get an occasional crash - but not as often.

 

What I've done is:

BCDEDIT /Set IncreaseUserVa 3072

 

Primarely I did this to see if it tipped the balance in either directions. I have no idea if it as any effect on the Wow64 node x86 emulation in a 64 bit system. It claims to be effective for 32bit Windows only. But is was worth a sling-shot.

The method to changes the system to maintain 1gb adresses for itself - and 3gb for user-mode virtual address space, compared to 2gb vs 2gb.

 

I havent flown the really heavy missions yet - so I can't really say for sure.

But Im keeping my fingers crossed.

 

And a big thanks to Fudd and Smil for sticking around keeping me airborne today. :)

Edited June 7, 2009 by Panzertard

[JG14_Smil]

I knew there was a reason I spent so much time flying yesterday :)

 

You know, I think I found your problem and it is an obvious one... (look at avatar) :)

[Panzertard]

NVG helps me to see ... :D

[c0ff]

What I've done is:

BCDEDIT /Set IncreaseUserVa 3072

 

Primarely I did this to see if it tipped the balance in either directions. I have no idea if it as any effect on the Wow64 node x86 emulation in a 64 bit system. It claims to be effective for 32bit Windows only. But is was worth a sling-shot.

I think it can affect 32-bit emulation as well - for (ms beloved) compatibility reasons.

 

I havent flown the really heavy missions yet - so I can't really say for sure.

But Im keeping my fingers crossed.

Looking forward for more of your updates :)

 

Thank you, for you patience and curiosity! I'm sure it pays back in all fields.

[Panzertard]

Update #9

Unfortunately - the BCDEDIT seem to have improved nothing.

With the "Near Gundelen - coop 2.miz" I can always produce the crash regardless of "BCDEDIT /Set IncreaseUserVA 3072" or not.

For those who have tried this trick, and wish to remove it - use "BCDEDIT /deletevalue IncreaseUserVA".

 

I'm out of ideas at the moment.

But I've made some reflections as well.

 

Reflection #1:

Why am I so able to produce the crash so consistently with the "Near Gundelen - coop 2.miz", flying in killing most of the targets and returning to base. (Works both with Client or Server - 1 or 2 players).

This may lead me to beleive there's something special in that mission - or the area where the mission is taking place.

Quite a few other MP mission (or servers out there) doesn't produce such a consistent result.

 

Reflection #2:

How it crashes out at the end of session - or if one tries ot change map - seems quite similar to how the Server's crash when someone rotates a map.

159'th server suffers from this alot - it runs for quite a few hours before anyone attempting to rotate the map - and it seem to always crash if it's been running for > 3 hours.

So this problem I am having - seem to be related to the server crashes.

Long sessions, whatever stacked up comes tumbling down when session need to change.

 

c0ff, if you or your peers have some debug versions or tools available I'm willing to run these to see if we can get some more data out of these incidents.

Personally I cannot find any more methods to try to change the outcome. ;)

[c0ff]

Thanks for the info, Panzertard.

 

Your evidence points to the main suspect - debrief.log writer.

I'll return from a vacation soon and check it out.

[Panzertard]

Thanks for the heads up c0ff - still, even though you are looking elsewhere to nail the issue - I still wanted to understand a bit more about the 32 bit vs 64 bit workings.

(all quotes in this post is taken from http://msdn.microsoft.com/en-us/library/bb147385(VS.85).aspx)

EDIT: Oh, I hope you're all rested and getting back up to speed after your vacation! :)

 

And I stumbled upon the definition/requirements of the adressable memory spaces:

 

Differences in Addressable Memory

 

 

 

The first thing most developers notice is that 64-bit processors provide a huge leap in the amount of physical and virtual memory that can be addressed.

• 32-bit applications on 32-bit platforms can address up to 2 GB
  
• 32-bit applications built with the /LARGEADDRESSAWARE:YES linker flag on 32-bit Windows XP or Windows Server 2003 with the special /3gb boot option can address up to 3 GB. This constrains the kernel to only 1 GB which may cause some drivers and/or services to fail.
  
• 32-bit applications built with the /LARGEADDRESSAWARE:YES linker flag on 32-bit versions of Windows Vista, and on 32-bit versions of Windows Server Code Name "Longhorn" operating systems, can address memory up to the number specified by the boot configuration data (BCD) element IncreaseUserVa. IncreaseUserVa can have a value ranging from 2048, the default, to 3072 (which matches the amount of memory configured by the /3gb boot option on Windows XP). The remainder of 4 GB is allocated to the kernel and can result in failing driver and service configurations.
  For more information about BCD, see Boot Configuration Data on MSDN.
  
• 32-bit applications on 64-bit platforms can address up to 2 GB, or up to 4 GB with the /LARGEADDRESSAWARE:YES linker flag.
  
• 64-bit applications use 43 bits for addressing, which provides 8 TB of virtual address for applications and 8 TB reserved for the kernel.
  

As you can see - with 32bit on the 64bit version we should technically be able to utilize 4Gb of adresses.

And that I could have gotten into trouble for messing about with the "IncreaseUserVa", or more frequent crashing if the system would run out of resources. Altough it can be reset quite easilly again.

 

But also - reflecting on the difficulties of coding for (compiling a true) 64 bit - my god, that seems quite strict, altought I understand the necessity of it:

 

Potential Compatibility Pitfalls

 

 

 

Most applications developed for a 32-bit platform will run without problems on a 64-bit platform. A few applications could have issues, which might include the following:

• All drivers for by 64-bit editions of Windows operating systems must be 64-bit versions. Requiring new 64-bit drivers has implications for copy-protection schemes that rely on old drivers. Note that kernel-mode drivers must be Authenticode-signed to be loaded by 64-bit editions of Windows.
  
• 64-bit processes cannot load 32-bit DLLs, and 32-bit processes cannot load 64-bit DLLs. Developers must ensure that 64-bit versions of third-party DLLs are available before proceeding with development. If you must use a 32-bit DLL in a 64-bit process, then Windows inter-process communication (IPC) can be used. COM components can also make use of out-of-process servers and marshalling to communicate between boundaries, but doing so may introduce a performance penalty.
  
• Many x64 processors .....
  

Well - just my reflections now that there's nothing more for us to do than waiting for the patch - and/or getting experimental 64bit support. Edited June 29, 2009 by Panzertard

[c0ff]

I'm on 64-bit Vista. BlackShark eats around 2.5 gigs accorrding to it's internal meter.

AFAIK, Vista maps all graphics memory into the process' address space.

So, if you have Graphics Card: XFX GeForce GTX 295 576M 1792MB, it means that all 4 gigs of available address space are used.

And poor BlackShark balances on the edge.

 

I changed debrief.log writer, so it does not store the log in memory. It should help.

But, still memory usage is close to the limit.

 

As for 64-bit build, sorry, not in this patch.

[Panzertard]

Ah that summarize pretty well how these issues, diagnostic data and results are tied together.

Thank you once again :)

 

No worries - well be greeting the experimental support with open arms whenever it appears for download and testing.

On a related note - is there a way for me to sign up for testing this / beta? Sign an NDA? Or perhaps it's for developer and partners only?

[c0ff]

On a related note - is there a way for me to sign up for testing this / beta? Sign an NDA? Or perhaps it's for developer and partners only?

You are welcome. Look into PM for details.

[Rob2222]

Hi all,

 

I created a relative huge multiplayer mission and now having the same problem. But I get this crash relative fast. But having a huge ammount of units in.

 

# -------------- 20090709-192251 --------------

D:\Spiele\Ka-50\bin\stable\MitkaGraphics.dll

# C0000005 ACCESS_VIOLATION at 12C29EBA 01:00028EBA

#

# EAX = 00000000

# EBX = 12CB8838

# ECX = 00000009

# EDX = 12CB8848

# ESI = 0EF6B800

# EDI = 00000000

# CS:EIP = 0023:12C29EBA

# SS:ESP = 002B:0017FBF8 EBP = 021C57A0

# DS = 002B ES = 002B FS = 0053 GS = 002B

# Flags = 00010246

 

 

Vista64, 4GB-RAM and GF 9800GTX+ with 512MB-GraphicRAM.

Does this problem affect 32 and 64 bit?

Is there a workaround possible? Less units? Or, let me ask, which units need the most memory? I could think that working artillery units need much memory?

 

BR Robert

[Panzertard]

Rob, I've seen a post somewhere here - stating "problems reagrding massive amounts of units" ... and "ended up recreating the mission with fewer units" ... not sure if it was using those words of course.

I think it might be related in ways - but there are no real workarounds for *this* issue it seems... yet.

 

Altough I could search for the post(s) - Im off to fly a little bit online right now - but if you find the relevant thread/posts, give us an update. Otherwise I might try to find it a bit later :)

[c0ff]

Does this problem affect 32 and 64 bit?

Is there a workaround possible? Less units? Or, let me ask, which units need the most memory? I could think that working artillery units need much memory?

Yep, both 32-bit and 64-bit systems are affected.

 

The workaround is to use less different _types_ of units. It is more important than the number of the units on it's own.

 

EDIT: The crash log you posted looks incomplete. Had you cut it, or it really looks like this?

Edited July 9, 2009 by c0ff

[Rob2222]

It really looks like it. The last was where I was client on Vista64 and my Laptop was Server on Vista32.

 

I just tried hosting (Server and playing) on Vista64. After some time the game frozen. I only came out with CTRL-ALT-DEL and THEN! the game crashes and gives that report.

 

I made a screenshoot of the memory usage at crash time in process explorer. Its attached.

 

This time crash was:

# -------------- 20090709-205928 --------------

D:\Spiele\Ka-50\bin\stable\MitkaGraphics.dll

# C0000005 ACCESS_VIOLATION at 131D9EBA 01:00028EBA

#

# EAX = 00000000

# EBX = 13268838

# ECX = 00000009

# EDX = 13268844

# ESI = 0EAEB800

# EDI = 13268842

# CS:EIP = 0023:131D9EBA

# SS:ESP = 002B:0017FBF8 EBP = 021657A0

# DS = 002B ES = 002B FS = 0053 GS = 002B

# Flags = 00010206

It is not cutted, it is all.

But I have to admit that this training MP mission is really big. I merged a campaign mission into this and have over 50 selectable (all different options) KA-50s.

Will try to cut down the type of used units.

 

 

EDIT: Just found the log at freeze time:

# -------------- 20090709-205814 --------------

C:\Windows\syswow64\kernel32.dll

# C0000005 ACCESS_VIOLATION at 77480DF9 01:00000DF9

#

# EAX = 00000001

# EBX = 34120A80

# ECX = 000000D8

# EDX = 0017F98C

# ESI = 69B5FB08

# EDI = 69AE29C8

# CS:EIP = 0023:77480DF9

# SS:ESP = 002B:0017F860 EBP = 6D30F4E0

# DS = 002B ES = 002B FS = 0053 GS = 002B

# Flags = 00010206

77480DF9 6D30F4E0 0001:00000DF9 C:\Windows\syswow64\kernel32.dll InterlockedIncrement()+9

77480DF9 6D30F4E0 0001:00000DF9 C:\Windows\syswow64\kernel32.dll InterlockedIncrement()+9

C83F0E2E 6D30F4E4 0000:00000000

C5C51AE2 6D30F4E8 0000:00000000

48E83902 6D30F4EC 0000:00000000

C8180045 6D30F4F0 0000:00000000

46F661C9 6D30F4F4 0000:00000000

48FB7153 6D30F4F8 0000:00000000

48ED90F2 6D30F4FC 0000:00000000

4AEDADBC 6D30F500 0000:00000000

80000E6B 6D30F504 0000:00000000

6D301862 6D30F508 0000:00000000

6D30F4E0 6D30F50C 0000:00000000

EDIT2: Are a russian KA-50 and a turkish KA-50 or a russian T72 and a georgian T72 different units?

Does random units that doesnt got activated count?

What will be savesd by less types? Garphic Card memory or main memory? Could you say some more details? (if known)

 

 

BR Robert

Edited July 9, 2009 by Rob2222

[Rob2222]

OK, one more try.

This time the virtual memory just was 1,6GB. :(

 

Server was notebook (Vista32), which was fine (no crash).

Client (Vista64) freeze.

 

Freeze Time log:

# -------------- 20090709-214432 --------------

D:\Spiele\Ka-50\bin\stable\CockpitBase.dll

# C0000005 ACCESS_VIOLATION at 1348E869 01:0009D869

#

# EAX = 00000002

# EBX = 4BB9AE30

# ECX = 525DA43C

# EDX = 0017F98C

# ESI = 00000000

# EDI = 52606E60

# CS:EIP = 0023:1348E869

# SS:ESP = 002B:0017F86C EBP = 52A23800

# DS = 002B ES = 002B FS = 0053 GS = 002B

# Flags = 00010202

1348E869 52A23800 0001:0009D869 D:\Spiele\Ka-50\bin\stable\CockpitBase.dll

1348E869 52A23800 0001:0009D869 D:\Spiele\Ka-50\bin\stable\CockpitBase.dll

C8463C09 52A23804 0000:00000000

C5C51AE2 52A23808 0000:00000000

48E6E426 52A2380C 0000:00000000

C8205A32 52A23810 0000:00000000

46F661C9 52A23814 0000:00000000

48FA72BC 52A23818 0000:00000000

CTRL-ALT-DEL Time Crash log

# -------------- 20090709-214535 --------------

D:\Spiele\Ka-50\bin\stable\MitkaGraphics.dll

# C0000005 ACCESS_VIOLATION at 12D09EBA 01:00028EBA

#

# EAX = 00000000

# EBX = 12D98838

# ECX = 00000009

# EDX = 12D98848

# ESI = 0EA8B800

# EDI = 00000000

# CS:EIP = 0023:12D09EBA

# SS:ESP = 002B:0017FBF8 EBP = 009657A0

# DS = 002B ES = 002B FS = 0053 GS = 002B

# Flags = 00010246

 

Can it be a error in my mission? I edited the mission file some time but I double checked all references. Which looks fine.

BTW, for what is the "currentKey" value?

 

BR Robert

[Panzertard]

As for the freeze - yes it "looks somewhat similar".

As for the rest (designing missions with large number of units) maybe another thread would be appropriate?

 

As for the currentKey - where did you see that reference? What do you mean? (Mission file content? If so, a new thread perhaps?).

[Rob2222]

Yes the currentkey is in the mission file but this is OT.

When removing half of the units I can play without crash. The funny thing is that it looks like no other players crash than me.

I have ServManMod installed cause sometimes I host with this machine. Maybe that is the cause. Will test next week without ServMan.

 

BR Robert