• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

General Protection Fault!

Jump to latest Follow Reply
Sort by date Sort by votes
J

Jiyuun

FNG / Fresh Meat
May 31, 2009
3
0
#1
Build KillingFloor_Build_[2009-02-09_10.82]

OS: Windows NT 6.0 (Build: 6001)
CPU: AuthenticAMD Unknown processor @ 2810 MHz with 4095MB RAM
Video: ATI Radeon HD 4800 Series (662)

General protection fault!

History: SkeletalMeshGet <- USpriteEmitter::UpdateParticles <- AEmitter::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=3) <- TickLevel <- UGameEngine::Tick <- Level KF-BioticsLab <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 4C576C61 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free

Third time its happened. Wtf!?
 
#3
I have been having a similar problem.

Build KillingFloor_Build_[2009-02-09_10.82]

General protection fault!

History: SkeletalMeshGet <- USpriteEmitter::UpdateParticles <- AEmitter::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=3) <- TickLevel <- UGameEngine::Tick <- Level KF-Doom2remake <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 4C576C61 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free
 
Upvote 0
#6
We appreciate the effort, but scattered threads is going to be the way things happen anyway, the masses will prefer chaos to organization ;)

We have reproduced the crash in the studio. Although it's quite sporadic, we should be able to use the info gathered internally and from the random threads with extra information. We have tracked it down to a specific line of code and we believe it has something to do with exploding a player or enemy that is on fire, but it's definitely not 100% of the time. There's probably a perfect timing that could get it 100% of the time, but we only need a decent reproduction in this case, which we believe we have.

Thanks again.
 
Upvote 0
#7
[TW]Xienen said:
We appreciate the effort, but scattered threads is going to be the way things happen anyway, the masses will prefer chaos to organization ;)

We have reproduced the crash in the studio. Although it's quite sporadic, we should be able to use the info gathered internally and from the random threads with extra information. We have tracked it down to a specific line of code and we believe it has something to do with exploding a player or enemy that is on fire, but it's definitely not 100% of the time. There's probably a perfect timing that could get it 100% of the time, but we only need a decent reproduction in this case, which we believe we have.

Thanks again.
Click to expand...
Great effort, it seems you're doing a lot of work to fix these bugs. My advice though is make everyone aware of what you're working at, because a lot of people on the general forums aren't seeing many posts and conclude that you're not doing anything to fix the issues. Maybe an announcemement just to inform everyone you are working on bug fixes?

The following thread backs up my point:
http://forums.tripwireinteractive.com/showthread.php?t=33068

Would hate to see a dedicated team be put down by unfair slander.
 
Last edited:
Upvote 0
#8
First of all thanks for the effort in trying to find the general protection fault error and narrowing it down ingame, but i want to also make aware that I also get the error when i try to start the game. My log is below:
Build KillingFloor_Build_[2009-02-09_10.82]

OS: Windows XP 5.1 (Build: 2600)
CPU: AuthenticAMD PentiumPro-class processor @ 1800 MHz with 767MB RAM
Video: No Video

General protection fault!

History: FMallocWindows::Free <- FMallocWindows::Free
Something is wrong with my video? Well I just wanted to post this. I understand that the team already has lots of bugs to work out so thanks in advance for any help :D
 
Upvote 0
#9
General Protection Faults are actually a sign of a variety of errors. Your particular issue is entirely different from the issue talked about in this thread. The actual type of error is defined by finding a common section in the output:

SkeletalMeshGet <- USpriteEmitter::UpdateParticles

This is a wide spread game created error that we have possibly fixed.

Your error is defined by FMallocWindows::Free, which tells me that it has something to with freeing up memory due to interaction issues with Windows or issues with your RAM.

I have seen your particular error from you a number of times and a few others have had similar errors. Unfortunately vash, we have not managed to get your particular error in the studio, so we are having a really hard time tracking down what's causing your General Protection Fault. We will continue to work on it, but at present, we have very little information to go on.
 
Upvote 0
#11
Hi!!

I am new here in the tripwire forums. I am here help if possible in the solution of this problem. My error happens mostly when using flametower and in the 9/10 or 10/10 wave >.<. This is the critical error message displayed right after crash:

Build KillingFloor_Build_[2009-02-09_10.82]

OS: Windows NT 6.0 (Build: 6001)
CPU: GenuineIntel PentiumPro-class processor @ 2618 MHz with 2047MB RAM
Video: NVIDIA GeForce GTX 260 (8585)

General protection fault!

History: SkeletalMeshGet <- USpriteEmitter::UpdateParticles <- AEmitter::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=3) <- TickLevel <- UGameEngine::Tick <- Level KF-Farm <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 4C576C61 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free

and the killingfloor.log:

Warning: ZombieClot KF-Farm.ZombieClot (Function kfmod.KFMonster.RemoveHead:008D) Attempt to assign variable through None
Critical: SkeletalMeshGet
Critical: USpriteEmitter::UpdateParticles
Critical: AEmitter::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=3)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: Level KF-Farm
Critical: UpdateWorld
Critical: MainLoop
Critical: FMallocWindows::Free
Critical: FMallocWindows::Realloc
Critical: 4C576C61 0 FArray
Critical: FArray::Realloc
Critical: 0*2
Critical: FMallocWindows::Free
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Log: Waiting for file streaming thread to finish...
Exit: OpenAL Audio subsystem shut down.
Localization: No localization: Window.IDDIALOG_CrashBox.IDC_CrashBox (int)
Exit: Exiting.
Log: FileManager: Reading 5 GByte 4771 MByte 4194332 KByte 145 Bytes from HD took 32.742750 seconds (32.460751 reading, 0.282000 seeking).
Log: FileManager: 5.117930 seconds spent with misc. duties
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 05/25/09 22:22:50

I think that actually you will find plenty of similar cases. I was really dissapointed thinking you were ignoring this issue guys so now I feel a lot better. These are the threads:

[url]http://forums.steampowered.com/forum...d.php?t=883113[/URL]

[url]http://forums.steampowered.com/forum...d.php?t=872351[/URL]

[url]http://forums.steampowered.com/forum...d.php?t=873599[/URL]

[url]http://forums.steampowered.com/forum...d.php?t=879360[/URL]

[url]http://forums.steampowered.com/forum...d.php?t=865617[/URL]


Thanks
 
Upvote 0
#12
[TW]Xienen said:
We have tracked it down to a specific line of code and we believe it has something to do with exploding a player or enemy that is on fire, but it's definitely not 100% of the time. There's probably a perfect timing that could get it 100% of the time, but we only need a decent reproduction in this case, which we believe we have.

Thanks again.
Click to expand...

Great to hear that you guys have the issue pin pointed, and thank you for looking into this issue and being so quick on the ball with it. I have seen those hard to reproduce, not 100% of the time issues go completely ignored for months, even years with other Developers, so this is truly refreshing.
 
Upvote 0
#13
Well, as much as some people have been complaining about our "lack of response", anyone who's been around through Red Orchestra's life knows that we at Tripwire truly support our games. We hate the issues within our game more than the players do, but there's only so much time in a day to fix them and not much that can be done when we can not reproduce the issue in studio. As soon as we know how to make something happen, though, we figure out why it is happening and fix it. That's just our style.

I hope we have fixed this crash for you guys, we'll see what happens after the next update.
 
Upvote 0
#14
Build KillingFloor_Build_[2009-02-09_10.82]

OS: Windows XP 5.1 (Build: 2600)
CPU: GenuineIntel PentiumPro-class processor @ 2403 MHz with 2047MB RAM
Video: No Video

General protection fault!


And some more text...not sure.This is what my friends game says after he has choosen Software instead of Direct 3D...re-installing didn't help and I'm surprised, why?Is there any way to change settings if game isn't launched?
 
Upvote 0
#16
BigDaddy said:
Build KillingFloor_Build_[2009-02-09_10.82]

OS: Windows XP 5.1 (Build: 2600)
CPU: GenuineIntel PentiumPro-class processor @ 2403 MHz with 2047MB RAM
Video: No Video

General protection fault!


And some more text...not sure.This is what my friends game says after he has choosen Software instead of Direct 3D...re-installing didn't help and I'm surprised, why?Is there any way to change settings if game isn't launched?
Click to expand...
Right click Killing Floor in Steam > Properties > Set Launch Options > and type "-d3d" exactly as it appears there, save changes, and fire it up. Should work swimmingly.

EDIT: Just read your response after. But at least you know that's the easier way to do it next time :)
 
Upvote 0
#18
This crashes tends to happen to me when we're dealing with a large swarm, tons of stuff is going on, and there's an explosion. What's weird is it happened shortly before I got Firebug Rank 3...and then we were exploding flaming zombies no problem. Sometimes it happens to one or two people in a game, sometimes it takes everyone in game down. Was kinda worried my system was just getting pushed over the limit....glad to see it's a bug in the code. (Sort of, anyways.)
 
Upvote 0
#19
[TW]Xienen said:
Well, as much as some people have been complaining about our "lack of response", anyone who's been around through Red Orchestra's life knows that we at Tripwire truly support our games. We hate the issues within our game more than the players do, but there's only so much time in a day to fix them and not much that can be done when we can not reproduce the issue in studio. As soon as we know how to make something happen, though, we figure out why it is happening and fix it. That's just our style.

I hope we have fixed this crash for you guys, we'll see what happens after the next update.
Click to expand...

I think the lack of response 'they' are reffering to is getting their issues addressed directly. It doesn't help 'they' feels the need to create thier own thread for the same problem over and over again that CoDKiller illustrates perfectly with those links...


I notice you guys are pretty damn swift on nailing the bugs as they come out, you pretty much slammed most of the big ones in the first patch then the 2nd one took care of a few more and improved a few things.


This general projection fault error I only see after about 20+ hours of playing, it never really bothered me that much honestly, and I figured you guys would nail it, and fingers crossed for the next patch nailing it.

Nice work team!
 
Last edited:
Upvote 0
You must log in or register to reply here.
Top Bottom
Back
Jump to latest Follow Reply
Jump to latest Follow Reply
Community News
Forums
Merch
Menu