• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Need help desperatly, STOP error

koss2010

Weaksauce
Joined
May 17, 2005
Messages
127
I have no idea what is going on ill try to explain it .

After 6 hours of my pc bieng shutdown i turn it on and ..

-It boots into windoes then restarts ..
-Boots again and tells me i got a stop error from my driver after a little longer interval of time restarts again (<5mins)
-On the THIRD boot it runs ROCK SOLID i prime95ed it for 9 hours ..

Ive also ran memtest with no errors !

Category: 102; Event ID: 1003; Description Error code 000000fc, parameter1 ec76cd64, parameter2 2a602163, parameter3 ec76cc1c, parameter4 00000001.; Data 0000: 53 79 73 74 65 6d 20 45 System E

This is a fairly new build, and i dont even knoe if its hardware or software and really dont wonna do a fresh install unless its a MUST

Things ive tried ..
- Disabled soundcard
- Uninstalled soundcard
- Boot at all stock
- Reinstall fresh drivers

ALL of which have had ZERO sucsess

Its been goin on for about a month but because it runs after 3 boots i ignored it for the most part.

Update: It happens EVERYTIME i physically press the power button !
Symbolic Name: ER_KRNLCRASH_LOG
 
koss2010 said:
Ive also ran memtest with no errors !

which is generally indicitive, but not definative

http://www.lostcircuits.com/memory/ultrax/

The advantage of having a non-DOS or Windows based test program is quite simple. If an operating system is running, the area of memory containing the OS or reserved for the OS cannot be tested correctly. Usually, the workaround in a situation like this is to alternate DIMMs between two memory slots since the operating system will be loaded onto the higher (Win9x) or the lower number DIMM (all other operating systems). Thus, by switching DIMMs back and forth between slots, one DIMM can always be kept free of the OS which, then allows complete testing of the module. The natural drawback is that every DIMM has to be tested twice which can be rather time-consuming.

something that is worth doing if you can
employing the proper ESD precautions of course ;)

relocated to operating systems

Troubleshooting Stop Errors
 
Did you see the sticky? I guess our moderators don't even refer to it. Bummer!

Is it 0xFC? If so, we'll need a dump to look into it. Or is it 0xFE? The 0xFE code is a pretty easy one to finger; it's a USB driver error.
 
Ice Czar said:
:p

Nice ;)

Ive been rather myoptically focused recently (on the lab) and missed that

Ive read the sticky several times now i was just asking because i want to solve this asap since my warranty on the hardware is slowly dying. Just seeing if anyone out there has some experince with this ...
 
Like I said here and in the sticky, we need more information.

Is it 0xFC or 0xFE? If it's 0xFE, then you've got a USB driver problem. If it isn't, post the dump and I can debug it for you.
 
the stop error should indicate what Driver it failed at.

something like FTDISK.SYS or any other driver.

Post everything on the first 5 lines.. that is all that is needed to TSR a stop error.
 
I found the 0xFC check in BugCodes.h in the DDK:

Code:
//
// MessageId: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY
//
// MessageText:
//
// An attempt was made to execute to non-executable memory.
//
#define ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY ((ULONG)0x000000FCL)

That means that you have a device driver which is trying to run code on the stack. No way to know if it's intentionally doing that or unintentionally doing that. You can learn more about DEP by reading the Data Execution Prevention article on TechNet. The XP SP2 version of the article might be a little different.
 
mikeblas said:
I found the 0xFC check in BugCodes.h in the DDK:

Code:
//
// MessageId: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY
//
// MessageText:
//
// An attempt was made to execute to non-executable memory.
//
#define ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY ((ULONG)0x000000FCL)

That means that you have a device driver which is trying to run code on the stack. No way to know if it's intentionally doing that or unintentionally doing that. You can learn more about DEP by reading the Data Execution Prevention article on TechNet. The XP SP2 version of the article might be a little different.

I read up on it, and it sounds like its a fishy driver somewhere ... do u think a fresh install might fix tht ?
 
If you can provide a dump, I can probably tell you exactly what driver is causing the problem.

Yes, it's a driver problem. Some driver is trying to execute code in memory that isn't marked as executable memory.

Some programmers write code like this on purpose; they should have changed the permissions on the memory to make it executable. That's how they'll fix the problem.

Other programmers are sloppy, and accidentally end up executing data -- right before they crash.

You don't have to reinstall everything; you just need to find the driver that's causing the problem and get it fixed or replaced.
 
mikeblas said:
If you can provide a dump, I can probably tell you exactly what driver is causing the problem.

Yes, it's a driver problem. Some driver is trying to execute code in memory that isn't marked as executable memory.

Some programmers write code like this on purpose; they should have changed the permissions on the memory to make it executable. That's how they'll fix the problem.

Other programmers are sloppy, and accidentally end up executing data -- right before they crash.

You don't have to reinstall everything; you just need to find the driver that's causing the problem and get it fixed or replaced.

Thanks for your response, i pmed you about the issue. I will try my best to provide as much info as i can.
 
Instructions for collecting the dump are in the sticky note.
 
Do u need the kernal dump or the complete dump ? Ill just get the complete to be on the safe side :D
 
The kernel dump is usually enough; making a complete dump available as a backup in case the kernel dump is zorched is helpful.
 
on the sinister side of the realm of possibility
malware can inject a dll, driver or service

and of course their batting average of getting it right (making it work)
Id say is slightly worse than the average legitimate code jockey

these days with rootkits so prevalent detection is that much harder
 
Ice Czar said:
on the sinister side of the realm of possibility
malware can inject a dll, driver or service
Yep. But applications can't cause blue screen failures ... only drivers can. Driver-based malware isn't exactly that common, since it's much harder to install a driver than a DLL or service. (Well, without the user noticing, anyway.)

Once koss2010 supplies a dump, It should be easy to pinpoint the cause.
 
Yep; it's certainly an execution protection fault saving you from executing a non-code area.

Code:
ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc)
An attempt was made to execute non-executable memory.  The guilty driver
is on the stack trace (and is typically the current instruction pointer).
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ec49ed64, Virtual address for the attempted execute.
Arg2: 2b883163, PTE contents.
Arg3: ec49ec1c, (reserved)
Arg4: 00000001, (reserved)

Does the blue screen or the entries in your system error log include the name of the driver causing the exception? figgie asked you this a while ago and I thought you had answered, but it looks like you ignored him.

Unfortunately, I'm not getting a good stack trace:

Code:
kd>   kb
ErrCode = 00000011
eax=7fff0000 ebx=0052febc ecx=0000000c edx=0052fe98 esi=0052ff04 edi=ec49ecf8
eip=ec49ed64 esp=ec49ec90 ebp=ec49ed44 iopl=0         nv up ei ng nz na pe cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010283
ec49ed64 d4fe             aam     ???
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  Args to Child              
WARNING: Frame IP not in any known module. Following frames may be wrong.
ec49ed44 8053c808 0052fecc 00000027 0052feec 0xec49ed64
ec49ed44 7c90eb94 0052fecc 00000027 0052feec nt!KiFastCallEntry+0xf8 [d:\nt\base\ntos\ke\i386\trap.asm @ 1436]
0052fe8c 00000000 00000000 00000000 00000000 0x7c90eb94

The address on the stack isn't attributed to any module you have loaded, but it is driver memory. The stack seems like it's already trashed by the execution.

I'll see if I can pick through the stack a little more, but if you're getting the driver name in the error message, then it would certainly help.
 
Bummer. I'll ask around at work about it, but I can't get anything out of the stack -- it's just too trashed. The IP is in a data area between two loaded drivers, but I don't know if I can assume it's the memory owner that's causing the problem.
 
Thanks mike .. but i think i know why you couldent find a driver.

Im gonna say this for anyone that gets the same error and searches google for it and ends up here.

Turned out it was my ram.
 
I'm glad you've got it solved.

You've replaced the ram and the problem just went away, without reformatting or reinstalling anything?
 
Back
Top