| Pages: [1] 2 3 :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 14 post(s) |
|
CCP Fallout
   |
Posted - 2011.01.24 19:36:00 -
[1]
No one likes crashes. They are immersion breaking, and just plain annoying. But you can help us minimize the number of crashes players experience. How? CCP Stillman's newest blog has all the details.
Fallout
Associate Community Manager
CCP Hf, EVE Online
Contact us |
|
Caiman Graystock
Caldari
Massively Mob
|
Posted - 2011.01.24 19:39:00 -
[2]
Nice portrait Fallout!
|
Durin Sarga
|
Posted - 2011.01.24 19:54:00 -
[3]
Very nice information. Glad to see how CCP is working to make our experience better.
Oh, and /ibc.
|
ShadowMaster
Gallente
|
Posted - 2011.01.24 19:55:00 -
[4]
Thanks for the blog and the insight.
|
northwesten
Amarr
Trinity Corporate Services
Novus Ordo Mundi
|
Posted - 2011.01.24 20:04:00 -
[5]
Edited by: northwesten on 24/01/2011 20:04:39
4th cant be  nice blog btw
|
Steve Thomas
Minmatar
|
Posted - 2011.01.24 20:05:00 -
[6]
I do wonder if you still have "Crashy" or is that setup obsolete. (Granted that one was tracking down a issue with (if I remember correctly) the firewall causing crashes.
|
Nemo deBlanc
|
Posted - 2011.01.24 20:09:00 -
[7]
So after reading this, here's my question:
Why can you not put some sort of code/program in place that can verify errors client side, and allow you to ascertain whether we're eligible for reimbursement?
The way I understand it currently, the only time you can get your losses replaced is in the event of a server side issue, and it's just tough luck if your client has an issue. If you're already collecting various bits of crash data from the clients, is there no way you could make something verify for you that a crash occurred with a game client? Losing a ship to crashes and disconnects is very frustrating, and there's no way for you to make sure that was legitimately the cause of a ship loss, therefore no reimbursement.
Is this something you've looked at? Or is there simply no way for you to verify client side problems without them being subject to some sort of cheating that would falsify client data?
(If I missed something obvious, my apologies. I don't pretend to have much knowledge about this stuff, which is why I'm asking)
|
Gnulpie
Minmatar
Miner Tech
|
Posted - 2011.01.24 20:15:00 -
[8]
Good stuff, worth reading!
Yay |
Iamien
Democracy of Klingon Brothers
R.A.G.E
|
Posted - 2011.01.24 20:25:00 -
[9]
 Originally by: CCP Fallout
No one likes crashes. They are immersion breaking, and just plain annoying. But you can help us minimize the number of crashes players experience. How? CCP Stillman's newest blog has all the details.
So what your saying is, that Windows forwards our personal system information without our consent to any third party that claims the be the developer of an executable?
I always thought the bug reports were private correspondence from my computer's memory to Microsoft, guess I was wrong.
|
Ambo
I've Got Nothing
|
Posted - 2011.01.24 20:29:00 -
[10]
Interesting insight into the crash logging process. Always wondered if those crash reports actually went anywhere 
Originally by: Nemo deBlanc
So after reading this, here's my question:
Why can you not put some sort of code/program in place that can verify errors client side, and allow you to ascertain whether we're eligible for reimbursement?
The way I understand it currently, the only time you can get your losses replaced is in the event of a server side issue, and it's just tough luck if your client has an issue. If you're already collecting various bits of crash data from the clients, is there no way you could make something verify for you that a crash occurred with a game client? Losing a ship to crashes and disconnects is very frustrating, and there's no way for you to make sure that was legitimately the cause of a ship loss, therefore no reimbursement.
Is this something you've looked at? Or is there simply no way for you to verify client side problems without them being subject to some sort of cheating that would falsify client data?
(If I missed something obvious, my apologies. I don't pretend to have much knowledge about this stuff, which is why I'm asking)
There are a few problems. One is that anything client-side can be tampered with.
While it would be possible to construct a system that would tell you with a high degree of certainty that what occurred was a legitimate crash, no system of that type can be 100% secure.
Even if it was, it would be trivial (as long as you knew what you were doing) to induce a crash at the press of a special key combination or similar. The 'crash generator' would become the must have cap pilot app.
Anyway, I'm sure you get the idea. Data coming from the client side cannot be trusted, plain and simple.
--------------------------------------
|
|
|
Victor Valka
Caldari
The Kairos Syndicate
Transmission Lost
|
Posted - 2011.01.24 20:32:00 -
[11]
Originally by: Iamien
Originally by: CCP Fallout
No one likes crashes. They are immersion breaking, and just plain annoying. But you can help us minimize the number of crashes players experience. How? CCP Stillman's newest blog has all the details.
So what your saying is, that Windows forwards our personal system information without our consent to any third party that claims the be the developer of an executable?
I always thought the bug reports were private correspondence from my computer's memory to Microsoft, guess I was wrong.
You should probably read Microsoft's privacy policy on this subject before making a fool out of yourself. I'll even link it for you. Section "Who can use the information and how can it be used? " is what you're looking for.
Originally by: Spaztick
You are not outnumbered, you are in a target-rich environment.
|
Borgh Brainbasher
Brutor Tribe
|
Posted - 2011.01.24 20:33:00 -
[12]
Originally by: Iamien
Originally by: CCP Fallout
No one likes crashes. They are immersion breaking, and just plain annoying. But you can help us minimize the number of crashes players experience. How? CCP Stillman's newest blog has all the details.
So what your saying is, that Windows forwards our personal system information without our consent to any third party that claims the be the developer of an executable?
I always thought the bug reports were private correspondence from my computer's memory to Microsoft, guess I was wrong.
:tinfoil:
its actually not your information they send on to ccp, its statistics about the kind of people that had the crash. so not "Iamien , who runs windows 3.1, crashed" but "some guy/gal/other, who uses windows 3.1 crashed" big difference.
|
Deakin Frost
Gallente
The Scope
|
Posted - 2011.01.24 20:43:00 -
[13]
I never understood why some games want to clean up their memory allocations when exiting.
Anarchy Online is/was another offender of this, especially because it took so goddamn long. When a process exits, Windows cleans up behind you. Faster and better than you can, too.
---
Inappropriate sig image removed -Abdalion |
Tsabrock
Gallente
Circle of Friends
|
Posted - 2011.01.24 20:45:00 -
[14]
An interesting blog. It certainly makes me think twice about not sending my memory dumps in, although it does take a while to send those crash reports.
That makes me wonder, how much data is actually transmitted in these crash reports these days? I know a while ago (XP Era I think), it'd transmit the entire contents of your system's RAM, and even 2 Gigs would take hours to upload. Now a days I run with 8 Gigs of RAM, and only 512Kb upload.
---
If you've read something I posted and want to contact me, EVE-Mail me, or contact me via EVE Gate. |
Nemo deBlanc
|
Posted - 2011.01.24 20:45:00 -
[15]
There are a few problems. One is that anything client-side can be tampered with.
While it would be possible to construct a system that would tell you with a high degree of certainty that what occurred was a legitimate crash, no system of that type can be 100% secure.
Even if it was, it would be trivial (as long as you knew what you were doing) to induce a crash at the press of a special key combination or similar. The 'crash generator' would become the must have cap pilot app.
Anyway, I'm sure you get the idea. Data coming from the client side cannot be trusted, plain and simple.
Does anybody bother to check out the actual client code though? I'm honestly thinking of a scenario where CCP would just sneak this into some patch and not tell anybody, and never make mention of it. Don't base reimbursements on that alone...but a variety of things. Stuff like "was the client restarted", "did the server receive no activity from the player before the time of the crash", etc.
Idk, I'm just thinking out loud here. I know blizzard uses "Warden" to spy on clients and help catch cheaters, and I haven't heard word of CCP using anything similar. I haven't yet heard of a warden hack, and that's got 12 million players or so. What's to say the 300k in Eve would crack and abuse a similar measure by CCP? I suppose they wouldn't have to, and could merely know how to force a crash in some way... Bah, just annoying. I of course had the same thought you did as I posed the question, but I was hoping I could hear an actual CCP thought/reply on it that might delve a bit deeper than my assumptions.
|
Mad Hatteras
|
Posted - 2011.01.24 20:50:00 -
[16]
What?
Windows does something Helpful?
What sort of tomfoolery is this?
|
Mynxee
|
Posted - 2011.01.24 20:56:00 -
[17]
Very interesting read. Nicely written, too.
What do you do in the case of Mac client crashes? Can similar information be provided somehow? If not, what is the approach taken to investigate such problems?
Life In Low Sec |
Hykke
Free Imperial Vikings
|
Posted - 2011.01.24 21:00:00 -
[18]
Wow this is the first time I've heard of anyone (besides Microsoft) actually using the crash information. Very nice to know!
|
ElfeGER
Deep Core Mining Inc.
|
Posted - 2011.01.24 21:04:00 -
[19]
0.5% to 0.9% end up crashed? outch
are these graphs ignoring the wine/crossover users?
|
|
CCP Stillman
|
Posted - 2011.01.24 21:08:00 -
[20]
Originally by: Mynxee
Very interesting read. Nicely written, too.
What do you do in the case of Mac client crashes? Can similar information be provided somehow? If not, what is the approach taken to investigate such problems?
While my only involvement with the Mac client in regards to crashes is that I watch trends and analyze the data we get from Tranquility, I know for a fact that we work very closely with Transgaming. Their dev blog here outlines how they approach issues, which also include crashes.
|
|
|
|
Bagehi
Association of Commonwealth Enterprises
R.A.G.E
|
Posted - 2011.01.24 21:10:00 -
[21]
Good read! Nice to see someone doing something with the crash data I upload.
This signature is useless, but it is red.
|
|
CCP Stillman
|
Posted - 2011.01.24 21:13:00 -
[22]
Originally by: ElfeGER
0.5% to 0.9% end up crashed? outch
are these graphs ignoring the wine/crossover users?
No, Wine/Crossover users are counted as Windows users.
I might add that shortly following Incursion 1.1, we averaged at 0.5% crashes per day, up until Incursion 1.1.1 which caused more crashes, which we're working hard on locating and fixing asap.
It's always our goal to get our crash rate way down. And we're starting to be able to react more quickly to these issues as we improve our technology. I won't personally be happy till we reach 0.2%.
|
|
Mynxee
|
Posted - 2011.01.24 21:13:00 -
[23]
Originally by: CCP Stillman
Originally by: Mynxee
Very interesting read. Nicely written, too.
What do you do in the case of Mac client crashes? Can similar information be provided somehow? If not, what is the approach taken to investigate such problems?
While my only involvement with the Mac client in regards to crashes is that I watch trends and analyze the data we get from Tranquility, I know for a fact that we work very closely with Transgaming. Their dev blog here outlines how they approach issues, which also include crashes.
Thanks...I missed that one somehow. *goes to read it*
Life In Low Sec |
|
CCP Stillman
|
Posted - 2011.01.24 21:17:00 -
[24]
Originally by: Nemo deBlanc
So after reading this, here's my question:
Why can you not put some sort of code/program in place that can verify errors client side, and allow you to ascertain whether we're eligible for reimbursement?
The way I understand it currently, the only time you can get your losses replaced is in the event of a server side issue, and it's just tough luck if your client has an issue. If you're already collecting various bits of crash data from the clients, is there no way you could make something verify for you that a crash occurred with a game client? Losing a ship to crashes and disconnects is very frustrating, and there's no way for you to make sure that was legitimately the cause of a ship loss, therefore no reimbursement.
Is this something you've looked at? Or is there simply no way for you to verify client side problems without them being subject to some sort of cheating that would falsify client data?
(If I missed something obvious, my apologies. I don't pretend to have much knowledge about this stuff, which is why I'm asking)
I really wish that was viable. I remember all too often crashing when jumping into a fight, only to crash and be in a pod when I log in. It was clearly a bug in the client, but obviously the GM couldn't verify that it was a result of a bug in the client.
And as already pointed out, there's some fundamental problems about detecting a "legitimate" crash. I can think of a number of ways to crash the EVE client to make it look like a legitimate crash.
So while it would be very nice to be able to do, it's not technically viable 
|
|
bonesbro
Legio Prima Victrix
|
Posted - 2011.01.24 21:21:00 -
[25]
Originally by: Iamien
So what your saying is, that Windows forwards our personal system information without our consent to any third party that claims the be the developer of an executable?
I always thought the bug reports were private correspondence from my computer's memory to Microsoft, guess I was wrong.
Someone else already linked the privacy policy, so I won't get into that. But I can talk a little bit about how the crash reporting works. I am a Microsoft developer, though I don't work on the crash-analysis stuff.
When something crashes, Windows captures the callstack, the set of "function foo called function bar called function baz, and baz crashed in this way at that memory offset". Then it takes a unique hash of that callstack and checks with the watson servers to see if that callstack has been reported. If it has, it just +1s it. If not, it reports the callstack as well as the memory allocated by each function (a "minidump"). It is also possible for the application's developer to say "I need more information about this particular crash" which can include a larger set of the app's memory. I don't remember whether it can ever read anything outside the application's memory, and I am sure that you do get asked before it sends along anything extra.
One of the most important things about reporting your crash is that you're +1ing it. Even the tenth time you hit that same damn crash. As a developer, you want to see what your top crashes are and fix those, so the more times you report a crash the more likely it is to be fixed.
And, of course, if you have a repeatable crash, make sure you file a bug report that includes the steps. Having repro steps makes fixing a crash a thousand times easier.
|
Btomo Cur
|
Posted - 2011.01.24 21:22:00 -
[26]
Wow. If it is really true that you appreciate bug reports, you should tell this to the people that handle them. Eve's bug reporting is the single most unhelpful thing I have ever seen in my life. I'd been assuming you told those folks to make the process painful on purpose, in hope of cutting down on bug reports.
If you're serious about wanting more bug reports, you need to start responding to them with something other than "Sorry, you didn't give us enough information, we're closing this" or "Sorry, we could not reproduce, we're closing this".
|
|
CCP Stillman
|
Posted - 2011.01.24 21:22:00 -
[27]
Edited by: CCP Stillman on 24/01/2011 21:27:17
Originally by: Iamien
Originally by: CCP Fallout
No one likes crashes. They are immersion breaking, and just plain annoying. But you can help us minimize the number of crashes players experience. How? CCP Stillman's newest blog has all the details.
So what your saying is, that Windows forwards our personal system information without our consent to any third party that claims the be the developer of an executable?
I always thought the bug reports were private correspondence from my computer's memory to Microsoft, guess I was wrong.
I'd definitely suggest you read the privacy policy put forward by Microsoft. What you see on the screenshot is exactly the information we get, together with the crash dumps that people submit(A crash dump that contains a call stack, no heap data). If you don't consent to providing any data, then you can decide to not submit any information and not be worried about privacy issues.
This system is entirely opt-in. I'll quote the important part of the privacy policy:
Quote:
If youÆre concerned that a report might contain personal or confidential information, you should not send the report.
EDIT:
This post explains it very very well to. Thanks bonesbro 
Originally by: bonesbro
Originally by: Iamien
So what your saying is, that Windows forwards our personal system information without our consent to any third party that claims the be the developer of an executable?
I always thought the bug reports were private correspondence from my computer's memory to Microsoft, guess I was wrong.
Someone else already linked the privacy policy, so I won't get into that. But I can talk a little bit about how the crash reporting works. I am a Microsoft developer, though I don't work on the crash-analysis stuff.
When something crashes, Windows captures the callstack, the set of "function foo called function bar called function baz, and baz crashed in this way at that memory offset". Then it takes a unique hash of that callstack and checks with the watson servers to see if that callstack has been reported. If it has, it just +1s it. If not, it reports the callstack as well as the memory allocated by each function (a "minidump"). It is also possible for the application's developer to say "I need more information about this particular crash" which can include a larger set of the app's memory. I don't remember whether it can ever read anything outside the application's memory, and I am sure that you do get asked before it sends along anything extra.
One of the most important things about reporting your crash is that you're +1ing it. Even the tenth time you hit that same damn crash. As a developer, you want to see what your top crashes are and fix those, so the more times you report a crash the more likely it is to be fixed.
And, of course, if you have a repeatable crash, make sure you file a bug report that includes the steps. Having repro steps makes fixing a crash a thousand times easier.
|
|
|
CCP Stillman
|
Posted - 2011.01.24 21:25:00 -
[28]
Originally by: Tsabrock
An interesting blog. It certainly makes me think twice about not sending my memory dumps in, although it does take a while to send those crash reports.
That makes me wonder, how much data is actually transmitted in these crash reports these days? I know a while ago (XP Era I think), it'd transmit the entire contents of your system's RAM, and even 2 Gigs would take hours to upload. Now a days I run with 8 Gigs of RAM, and only 512Kb upload.
When you submit a crash dump, it does not submit a full memory dump from the program, but it rather cuts out the important part, which is a call stack and some very limited amount of the data that was being used at the time of the crash. When we get the crash dumps, they're about 1.5mb small. When we extract them, the crash dump itself is about 7mb.
So even on an average connection, you'll hopefully not be more than 1 minute to submit it.
|
|
Nemo deBlanc
|
Posted - 2011.01.24 21:25:00 -
[29]
Originally by: CCP Stillman
I really wish that was viable. I remember all too often crashing when jumping into a fight, only to crash and be in a pod when I log in. It was clearly a bug in the client, but obviously the GM couldn't verify that it was a result of a bug in the client.
And as already pointed out, there's some fundamental problems about detecting a "legitimate" crash. I can think of a number of ways to crash the EVE client to make it look like a legitimate crash.
So while it would be very nice to be able to do, it's not technically viable
Ah, disappointing, but pretty much what I figured. Thanks for confirming though, I enjoy the dev/player interaction a lot, regardless of the news I'm getting. Keep up the great work. (a bit off topic, but eh...something I just wanted to say. lol)
|
|
CCP Stillman
|
Posted - 2011.01.24 21:30:00 -
[30]
Originally by: bonesbro
One of the most important things about reporting your crash is that you're +1ing it. Even the tenth time you hit that same damn crash. As a developer, you want to see what your top crashes are and fix those, so the more times you report a crash the more likely it is to be fixed.
I just want to repeat once again what bonesbro pointed out. As mentioned in the dev blog, these reports are very important to give us visibility into what crashes needs to be fixed most urgently. Otherwise, a legitimate crash could end up being filtered out by us as just "noise". The more reports, the sooner it will be fixed.
|
|
|
|
|
|
| |
|
| Pages: [1] 2 3 :: one page |
| First page | Previous page | Next page | Last page |