Jump to content

Crash To Desktop After 5 Sec.


30 replies to this topic

#1 GHOST AQC

    Member

  • Members
  • Pip
  • Overlord
  • Overlord
  • 11 posts

Posted 28 April 2013 - 01:07 PM

Since the last patch, about 1 in 10 games crashes to desktop and always right after the match starts. I use Nvidia cards and have tried the usual restarting, clearing cache and even limited my FPS to 41. Anyone else getting this?

#2 Ninjai

    Member

  • Members
  • PipPipPip
  • 84 posts
  • LocationBehind you

Posted 29 April 2013 - 06:19 AM

View PostGHOST AQC, on 28 April 2013 - 01:07 PM, said:

Since the last patch, about 1 in 10 games crashes to desktop and always right after the match starts. I use Nvidia cards and have tried the usual restarting, clearing cache and even limited my FPS to 41. Anyone else getting this?


Hey Ghost,

Have you tried Krist freshly baked out of the oven repair tool?
http://mwomercs.com/...public-release/

Direct link to download:
http://patcher.mwome...ORepairTool.exe

In this particular case, we believe simply deleting the shader folder would do the trick (and much faster than running the repair tool), so you maybe you could try it first.

Default location should be here:
C:\Games\Piranha Games\MechWarrior Online\USER\Shaders

Please let us know if that worked.

#3 Karl Berg

    Backend Slayer™

  • Staff
  • Overlord
  • Overlord
  • 276 posts
  • LocationVancouver

Posted 29 April 2013 - 01:08 PM

Hey everyone. Just a quick heads up that a major cause of crash to desktop issues was identified from the crash dumps last friday, and a fix has been given to QA for emergency testing and launch. Not sure of when exactly this will end up getting patched out, but this issue is severe enough that will be rushed through with a very high priority.

Detailed reason for the crash if you're curious:

We recently introduced code making use of the MASKMOVDQU SSE instruction to write out only the first 4-bytes of a result from a 16-byte SSE register coming out of a hand-optimized function. Turns out that this instruction pulls in a full 128 bits of data from main memory, does the masked update on CPU, and then writes the full 128 bits back out to main memory regardless of which bytes were actually changed.

I've not made use of this particular instruction before, and the documentation didn't hint that this might be an issue, even though now it seems pretty obvious in hindsight :(. So if we were unlucky enough that the memory address we were writing back to was aligned right next to another page marked as unwritable, the kernel would generate an access violation.

#4 KOKO

    Member

  • Elite Founder
  • Overlord
  • Overlord
  • 30 posts
  • Facebook: Link
  • LocationGermany

Posted 29 April 2013 - 01:31 PM

Ok, this will fix the CTD issue. If you also can handle the game freeze issue (introduced with the February patch), the game would be stable for me again. I allready sent it to the support (#78619). You can find a LOT of threads in your forums. Best way using Google:

1st: "cryengine command buffer overflow" ... you get this, if you play in window fullscreen, the game hang and closes after confirming the OK button of the error-window.

2nd: "mwo missile freeze": The game just freezes (most of the time on missile hits) Can only be killed in the task manager. This error occurs, if you play in fullscreen mode. I think personally, that 1st and 2nd errors are the same, but you only can see the error message in window-fullscreen.

On both you will find a lot of answers to the thread starters. I hope you also will find the problem soon.

Best regards,

Tim

EDIT: And yes, i tried everything ... cleared the cache very often, different graphic drivers, reinstall, repair tool.

Edited by KOKO, 29 April 2013 - 01:33 PM.


#5 BlackWidow

    Member

  • Legendary Founder
  • Overlord
  • Overlord
  • 1178 posts
  • LocationPhoenix, Arizona

Posted 29 April 2013 - 01:51 PM

View PostKarl Berg, on 29 April 2013 - 01:08 PM, said:

Hey everyone. Just a quick heads up that a major cause of crash to desktop issues was identified from the crash dumps last friday, and a fix has been given to QA for emergency testing and launch. Not sure of when exactly this will end up getting patched out, but this issue is severe enough that will be rushed through with a very high priority.

Detailed reason for the crash if you're curious:

We recently introduced code making use of the MASKMOVDQU SSE instruction to write out only the first 4-bytes of a result from a 16-byte SSE register coming out of a hand-optimized function. Turns out that this instruction pulls in a full 128 bits of data from main memory, does the masked update on CPU, and then writes the full 128 bits back out to main memory regardless of which bytes were actually changed.

I've not made use of this particular instruction before, and the documentation didn't hint that this might be an issue, even though now it seems pretty obvious in hindsight :(. So if we were unlucky enough that the memory address we were writing back to was aligned right next to another page marked as unwritable, the kernel would generate an access violation.


You. Are. Awesome.

That is all.

#6 MajorChunks

    Member

  • Elite Founder
  • Storm
  • Storm
  • 41 posts
  • LocationOntario, CA

Posted 01 May 2013 - 07:24 AM

View PostKarl Berg, on 29 April 2013 - 01:08 PM, said:

Hey everyone. Just a quick heads up that a major cause of crash to desktop issues was identified from the crash dumps last friday, and a fix has been given to QA for emergency testing and launch. Not sure of when exactly this will end up getting patched out, but this issue is severe enough that will be rushed through with a very high priority.

Detailed reason for the crash if you're curious:

We recently introduced code making use of the MASKMOVDQU SSE instruction to write out only the first 4-bytes of a result from a 16-byte SSE register coming out of a hand-optimized function. Turns out that this instruction pulls in a full 128 bits of data from main memory, does the masked update on CPU, and then writes the full 128 bits back out to main memory regardless of which bytes were actually changed.

I've not made use of this particular instruction before, and the documentation didn't hint that this might be an issue, even though now it seems pretty obvious in hindsight :(. So if we were unlucky enough that the memory address we were writing back to was aligned right next to another page marked as unwritable, the kernel would generate an access violation.


I'm really liking all these awesome, highly-technical responses coming out. Please continue. Also, reading the words "hand-optimized" makes me all warm and fuzzy inside.

#7 Lugh

    Member

  • Legendary Founder
  • 1233 posts

Posted 01 May 2013 - 03:05 PM

Faster please Karl!

#8 GrizzlyViking

    Member

  • Legendary Founder
  • Overlord
  • Overlord
  • 986 posts
  • LocationSouth Carolina

Posted 01 May 2013 - 05:45 PM

Just fix it!

#9 Deathlike

    Member

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 10311 posts
  • LocationBoston Strong

Posted 01 May 2013 - 06:04 PM

View PostMajorChunks, on 01 May 2013 - 07:24 AM, said:


I'm really liking all these awesome, highly-technical responses coming out. Please continue. Also, reading the words "hand-optimized" makes me all warm and fuzzy inside.


Hand-optimized is fine.. but you have to VALIDATE to make sure the results are "working as intended". Judging from the technical response, it clearly wasn't.

At least we know they are at least trying to optimize... but they need better tools to make sure stuff isn't broken when stuff is added/changed.

Edited by Deathlike, 01 May 2013 - 06:04 PM.


#10 SmokinDave73

    Member

  • Elite Founder
  • Overlord
  • Overlord
  • 284 posts
  • LocationAlpheratz, Outer Sphere Periphery

Posted 02 May 2013 - 06:48 AM

View PostKarl Berg, on 29 April 2013 - 01:08 PM, said:

Hey everyone. Just a quick heads up that a major cause of crash to desktop issues was identified from the crash dumps last friday, and a fix has been given to QA for emergency testing and launch. Not sure of when exactly this will end up getting patched out, but this issue is severe enough that will be rushed through with a very high priority.

Detailed reason for the crash if you're curious:

We recently introduced code making use of the MASKMOVDQU SSE instruction to write out only the first 4-bytes of a result from a 16-byte SSE register coming out of a hand-optimized function. Turns out that this instruction pulls in a full 128 bits of data from main memory, does the masked update on CPU, and then writes the full 128 bits back out to main memory regardless of which bytes were actually changed.

I've not made use of this particular instruction before, and the documentation didn't hint that this might be an issue, even though now it seems pretty obvious in hindsight :(. So if we were unlucky enough that the memory address we were writing back to was aligned right next to another page marked as unwritable, the kernel would generate an access violation.


I have not experienced a crash to desktop since closed beta, now I carash to desktop about 1 in 5 games how does this coding get past a internal alpha server??? Plus is this not a high priority bug yet im pretty sure 90% of the player base is getting crash to desktop now.....

#11 MajorChunks

    Member

  • Elite Founder
  • Storm
  • Storm
  • 41 posts
  • LocationOntario, CA

Posted 02 May 2013 - 06:49 AM

View PostDeathlike, on 01 May 2013 - 06:04 PM, said:

At least we know they are at least trying to optimize... but they need better tools to make sure stuff isn't broken when stuff is added/changed.



True, but I've debugged low-level C and NASM assembly memory problems before, and I almost threw myself off of a bridge because of it. The fact that these guys can deal with it at all, and have the stones to admit when they messed up, earns them huge points in my book. You're right, it doesn't stop them from needing better regression testing, but we already knew that ;)

Edited by MajorChunks, 02 May 2013 - 06:50 AM.


#12 DragonsFire

    Member

  • Legendary Founder
  • Overlord
  • Overlord
  • 629 posts

Posted 02 May 2013 - 09:55 AM

View PostSmokinDave73, on 02 May 2013 - 06:48 AM, said:


I have not experienced a crash to desktop since closed beta, now I carash to desktop about 1 in 5 games how does this coding get past a internal alpha server??? Plus is this not a high priority bug yet im pretty sure 90% of the player base is getting crash to desktop now.....


Unfortunately internal test servers are not the same thing as a real world deployment and as a result things can and do get missed. It's the nature of the beast, but it's also why we're here. As for the actual CTD, I too haven't had much of it since CB, but after the most recent patch, I had 2 happen pretty close to one another. Did a full uninstall and reinstall of the client and all is right with the world again, at least for me.

#13 Karl Berg

    Backend Slayer™

  • Staff
  • Overlord
  • Overlord
  • 276 posts
  • LocationVancouver

Posted 02 May 2013 - 10:00 AM

The function was in fact performing perfectly fine. For a given set of inputs, the output was exactly what was expected; and we did run unit testing to confirm this. Unfortunately the chance of crashing was extremely random, since it mattered where in memory the function was told to store its results, and even if the return address crossed a page boundary, what the access permissions of that next page were.

Of course, none of this excuses us from missing this issue during testing; and for that we definitely apologize. The hotfix for this has made its way all the way to stage, and we are planning to patch this on production tomorrow morning.

#14 SmokinDave73

    Member

  • Elite Founder
  • Overlord
  • Overlord
  • 284 posts
  • LocationAlpheratz, Outer Sphere Periphery

Posted 02 May 2013 - 10:08 AM

View PostKarl Berg, on 02 May 2013 - 10:00 AM, said:

The function was in fact performing perfectly fine. For a given set of inputs, the output was exactly what was expected; and we did run unit testing to confirm this. Unfortunately the chance of crashing was extremely random, since it mattered where in memory the function was told to store its results, and even if the return address crossed a page boundary, what the access permissions of that next page were.

Of course, none of this excuses us from missing this issue during testing; and for that we definitely apologize. The hotfix for this has made its way all the way to stage, and we are planning to patch this on production tomorrow morning.


Thanks for the info, and I do understand that errors from time to time get through testing its just the CTD is by far the most frustrating bug of them all. Hopefully this hotfix helps the situation.

#15 Jack Lowe

    Member

  • Elite Founder
  • Guardian
  • Guardian
  • 158 posts
  • LocationStaten Island, NY

Posted 02 May 2013 - 10:20 AM

Excellent Karl thank you very much for the update, and particularly the explanation. Very helpful and for such an annoying bug it actually helps to know what the problem was. The fix may in fact affect some of the other bugs related to CTD. I'll certainly put in a few more games on my days off next week and see how it goes. If anything new pops up or some known problems seem less frequent I'll put it up here someplace.

#16 Krzysztof z Bagien

    Member

  • Members
  • PipPipPipPipPipPipPip
  • 700 posts
  • LocationŚwinoujście, Poland

Posted 02 May 2013 - 11:04 AM



#17 MajorChunks

    Member

  • Elite Founder
  • Storm
  • Storm
  • 41 posts
  • LocationOntario, CA

Posted 02 May 2013 - 12:46 PM

View PostKarl Berg, on 02 May 2013 - 10:00 AM, said:

The function was in fact performing perfectly fine. For a given set of inputs, the output was exactly what was expected; and we did run unit testing to confirm this. Unfortunately the chance of crashing was extremely random, since it mattered where in memory the function was told to store its results, and even if the return address crossed a page boundary, what the access permissions of that next page were.

Of course, none of this excuses us from missing this issue during testing; and for that we definitely apologize. The hotfix for this has made its way all the way to stage, and we are planning to patch this on production tomorrow morning.


You guys rock. Don't let anyone tell you otherwise.

#18 Naotaka

    Member

  • Legendary Founder
  • Overlord
  • Overlord
  • 33 posts
  • LocationNetherlands

Posted 03 May 2013 - 06:09 AM

View PostKarl Berg, on 29 April 2013 - 01:08 PM, said:

it seems pretty obvious in hindsight :(


Hindsight is 20/20 my friend. Chalk it up as useful experience gained.

Keep rocking.

#19 Karl Berg

    Backend Slayer™

  • Staff
  • Overlord
  • Overlord
  • 276 posts
  • LocationVancouver

Posted 03 May 2013 - 10:02 AM

The hotfix is up now, so this specific crash to desktop should be fixed. As always, it's a big help to us if you file a report and submit a crash dump when you do encounter a crash.

Thanks!

#20 Lugh

    Member

  • Legendary Founder
  • 1233 posts

Posted 03 May 2013 - 10:10 AM

Woot so I can patch and play and hopefully not see any more CTDs..





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users