stackhash error when closing fsx

[flyingnoob 25]

Hey folks, not exactly a ctd but kinda similar.

 

 

This started today after i reinstalled fsx, utx, pmdg md11

 

Problem Event Name: BEX

 

Application Name: fsx.exe

 

Application Version: 10.0.61472.0

 

Application Timestamp: 475e17d3

 

Fault Module Name: StackHash_0a9e

 

Fault Module Version: 0.0.0.0

 

Fault Module Timestamp: 00000000

 

Exception Offset: 04246c81

 

Exception Code: c0000005

 

Exception Data: 00000008

 

OS Version: 6.1.7601.2.1.0.768.3

 

Locale ID: 2057

 

Additional Information 1: 0a9e

 

Additional Information 2: 0a9e372d3b4ad19135b953a78882e789

 

Additional Information 3: 0a9e

 

Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

 

 

Any help with this going?

 

Regards

[Jim Young 2,356]

Hi Paul,

 

Sorry to hear you are still having problems. This crash (well, not really a crash) is exactly like this one just posted today - http://forum.avsim.net/topic/400368-fsx-stopped-working/. There is no 'known' solution other than to reinstall Windows and FSX.

 

Best regards,

Jim

[flyingnoob 25]

Hi Jim,

 

Thanks for that, if its no big deal, then i will carry as is, - if its not broke -- its just a little annoying, and i dont fancy reinstalling windows YET again, i have had it crash on both windowed and full screen(im sure as i am/have ben using both trying out tweaks)

 

Thank you again,

 

Paul

[Jim Young 2,356]

Hi Paul

 

Totally agree. It was annoying for me too and I had no plans on reinstalling everything until I ran into a bad driver for one of my HDD's and had to reinstall Windows. Maybe someone will discover a fix.

 

Best regards,

Jim

[flyingnoob 25]

Hi again Jim,

 

Will this error throw up any more surprises do you think? as i am now reconsidering re-installing windows - i CBA TBH, but its one of those things that is annoying me now, especially as it wasn't always like that, - again it only happened after i installed fsinn - like the other issue i had.

When i first installed windows my bios was set to defaults, should i have set my bios to XMP as stated by G.skill(and most other ram companies etc - after windows is installed is when i have then changed it - although it would not have made a difference to the boot priority issues i am having, as they have been erratic with defaults set all through all W7 installs.

 

Thanks

 

Paul

[Jim Young 2,356]

It shouldn't do any harm or mess up your FSX at all. It might even eventually go away. I'm toying with the thought that maybe removing a couple of memory simms from your system, running, Windows, shutting down, then reinstalling the simms might clear up the issue too. Never tried it and I don't really see this as a solution with my research on the Internet. Here's some info I found, in laymen's terms on StackHash issues:

 

Stack Hashes are basically data from programs that are in memory, that is unreserved for that program.

 

You see there is memory reserved for each program when it starts. The data from the program is extrapolated by the processor and sorted out in the processor cache if it overloads the processor cache it is feed into memory addresses that are reserved for that use, for the use of the processor to sort out the program, as it is loading.

 

A application will fail, or crash when that code is copied into memory and it loses some data. Data loss happens because the memory still has static built up in it that was not cleared properly or it simply ran out of room and over wrote the memory that was previously there, stringing the data together confusing the processor when it tries to load the program. This would explain why it happens when you right click on a program, or open it. It can also happen if you are playing video or music.

 

Video and music data does not look different but, if a block of data overwrites another, even if the memory has been cleared by the processor, static electricity is very volatile. The science of using static electricity is really young. Electrostatic discharge from your body can cause serious damage to your memory and has to be refreshed constantly. Electrostatic discharge from your body can burn out everything on your motherboard. They have that hexadecimal code such as 7f04 or ac62, because that is the address in memory of the faulty code.

 

It can also happen if it pushes the data into memory blocks and can’t remember it did. This is called buffer overrun. It has too much Data to process at the time and it overruns the buffer and is pushed into those reserved blocks of memory I referred to. Buffer overrun is not a myth, it is common and most occasions when it happens, the memory holds it, the processor knows where it is and what it is, but, a certain small percentage is not.

 

The answer to the problem is to make sure you have enough memory. Other than that, well it is a bug. A hardware/software interaction type of bug. A bug that cannot be solved by any fix besides that. Watch your memory usage levels when you do it, if you can. How much memory are you using? You can simply right click on an item and all the sudden crash, the application fails.

 

It is a clash of data. Don’t let it bother you, when it happens shut down your computer for like 30 seconds so that the static memory is cleared naturally and watch your memory usage.

Its a way for your computer to say I can’t take it anymore, I need a bit of a break.

 

Or if it happens frequently like a couple of times an hour, a few times a day, you need new memory or more memory. Depending on whether you are redlining during normal usage or not. Because if it is then your computer needs new memory, if it happens constantly at the same hexadecimal address, you are going to have to buy new memory anyway because it is Farked.

 

Answer buy some good memory. Or go easy on the memory you have it’s not fool proof you know, Nothing is fool proof.

 

should i have set my bios to XMP as stated by G.skill(and most other ram companies etc - after windows is installed is when i have then changed it - although it would not have made a difference to the boot priority issues i am having, as they have been erratic with defaults set all through all W7 installs.

 

Using the XMP Profile in your BIOS provides the best usage for your installed memory. It provides the highest frequency and the best voltage setting. Open up CPU-Z (you can download from the Internet), and look under the SPD tab. It provides the different frequencies your memory is rated. The XMP setting is usually on the far right side. You just have to set the frequency, timings and DRAM voltage as indicated in that column.

 

Best regards,

 

Jim

[flyingnoob 25]

i jim, thanks for the info, i will remove the ram, carefully, and reseat it on the off chance.

I only have 2X4GB sticks which is enough for what im doing.

With regards to the xmp profile - i understand tat, i was just curious if i should ave had that set in the bios prior to installing windows or if i should have left it at default(which i did do)

 

I dont want to reinstall everyting, as pmdg are bound to be getting annoyed with me constantly having to request my extended download to be reactivated(well its silly only having a 1 week long url!!) but nevertheless.

 

Also, the stackhash errors are only when i shut fsx down, no right issues or that (although i did have a right click issue earlier where my drop down(ie cockpit view/spot view etc) the menu was 2-3" below the cursor, and when i went to spot view, it was a strange elongated view.

 

Thanks for looking for all the info Jim, much appreciated.

 

Kind ergards

 

Paul

[Bob Scott 7,795]

Jim, that explanation of the stackhash fault module name has had me gut-laughing for 15 minutes! I was waiting for it to conclude with something like that the error was caused by not enough anti-static lubrication on the memory bus support bearings hehe. It reflects a poor underlying understanding of the issue at hand...especially the black magic-like attribution of these problems to static electricity.

 

Windows shows StackHash_HHHH as the faulting module as a fallback when it cannot identify a loaded module at the memory address of the instruction that was being executed when a DEP error is trapped. A hash code computed on the contents of the instruction stack is just a shorthand way of identifying what was on the address stack when the fault occurred--if multiple crashes occur with the same hash, then it points to a possibly deterministic and reproducible error. These sorts of errors are caused by the same sorts of faults that produce other memory addressing faults--it can be unstable or faulty hardware, or a host of programming or data errors, any of which can cause the CPU to try loading an instruction from a bad address.

 

Unstable or faulty hardware problems can usually be ferreted out with test programs like MEMTEST 86+, Prime 95, OCCT etc. And they typically will show up when running software other than FS as well. Errors resulting from software-specific problems include such problems as corrupted code (often caused by bit errors during disc writes due to unstable overclocks), buffer overruns (where a pointer into a section of memory set aside as a buffer goes outside the bounds of that buffer, causing data to be written outside the intended area and unintentionally overwriting other adjacent code and/or data), or bad pointers resulting from corrupted data (i.e. bad FSX textures) causing non-robust program code--which could be FSX, add-ons, or even system drivers--to become unruly because it can't gracefully handle the bad data, etc.

 

Unfortunately, when stackhash_HHHH shows up, it doesn't lend itself to a quick and easy ID of the problem's origins. It takes a lot more detective work, often the trial-and-error variety to isolate problems through a process of elimination. If I start seeing a problem like this, I start with the easy stuff--run a full suite of memory and system stress test profiles, and if that is unproductive, back off on overclock and see if the problem still occurs at stock speeds. If that doesn't shine a light on the problem, I'll try removing the last known software changes one-by-one (I keep a running log of every fault I experience and every change I make to my FSX machine for this reason). If a reasonable amount of backtracking doesn't fix the problem, I generally then conclude I have some kind of corruption--first I start with a system restore from my last backup before the problems started occurring, and if that doesn't help, rebuilding Rome with a Windows + FSX reinstall is the last resort.

 

Regards

[flyingnoob 25]

Hi Bob, thanks for chipping in here,

the pc is 2 weeks old, and it only done it for the first time, when i made the post,

I am prime stable 4 hrs @4.7 ram 2400, memtest runs fine 7 passes.

 

I am having issues regarding windows not booting to windows but staying at post screen till i go to bios and manually select boot priority for my 64GB ssd(O/S) could this be an issue aswell?

 

Currently i am on asus/crucial/here AND overclock.net trying to get round this issue.

 

Regards

 

Paul

 

Sorry for the bold, i have no idea how that happened!!

[Jim Young 2,356]

Jim, that explanation of the stackhash fault module name has had me gut-laughing for 15 minutes!

 

That's pretty harsh there Bob. I have been watching your posts in the CTD and AVSIM forums for many years and they usually are very negative toward the person who made a recommendation on how to fix a problem. My information came through several Google searches and a lot of research because, for one, I had a StackHash error myself a few months ago. My comments above provide a basic explanation, in laymen's terms, of a StackHash crash. Static electricity was used as an example of the issue at hand and in laymen's terms. (I will use the example in the future if I have to). The DEP explanation just doesn't hold any water with FSX as it cannot be excluded for the FSX program. It certainly is a potential solution for other computer programs though. As I have explained in numerous threads regarding the Stackhash problem, I fixed my problem with a reinstall of Windows and FSX and I lived with the issue for a few months before having to reinstall Windows. You normally can still run FSX and your computer system even though you get a StackHash as the crash usually appears when you close FSX. You have copied and pasted a lot of info about your assessment (expertise) of the Stackhash but there is no common cure and your post certainly does not help the situation here in resolving this problem for Paul. The simple solution I provided was to live with it until you have to reinstall Windows. That may or may not fix the problem for Paul but it is a known solution. To continue to copy and paste information here from all over the web does no good. To make fun of me (yes you did) as I was trying to help a fellow member does no good either. If you are knowledgeable of computers and how they function, the CTD forum is an excellent way for you to help fellow members with their problems. I hope you exercise that capability in the future.

 

Sincerely,

Jim Young

[Bob Scott 7,795]

That's pretty harsh there Bob. I have been watching your posts in the CTD and AVSIM forums for many years and they usually are very negative toward the person who made a recommendation on how to fix a problem.

 

Jim, no intent to offend you. I'm not being negative towards, or making fun of you. I knew that the bold-printed text pasted into your post wasn't your doing when I said that it (the pasted text) had me laughing.

(see http://tdistler.com/2009/04/10/stackhash-and-application-crashes-on-windows )

 

For background, I have a 4-year degree in Computer Science plus some post-grad work in the field, taught it at the university level, and now for fun I write add-on software for MSFS. The explanation pasted above in bold print is grossly inaccurate throughout, and even at a "laymen" level does not convey a proper understanding of how an error identifying StackHash_XXXX as the faulting module occurs, or what it really means (or for that matter how RAM works). I consider the pasted in text to be wildly inaccurate garden-variety non peer-reviewed internet folklore and not particularly helpful to someone trying to get their head around what's going on.

 

There's no such thing as a "stackhash crash" per se. To reiterate what I posted above, StackHash_XXXX is listed as the faulting module in any case where the OS traps a fault--DEP or other--and cannot match the address of the offending instruction with a module loaded by the OS into memory. It would be much more accurate to refer to it as a "crash of unknown origin." It can be caused by a bad overclock, failing/failed hardware, program bugs, bad data...pretty much the whole spectrum of things that can go wrong. So it generally doesn't give you much more detail than there's a problem somewhere.

 

If you go back and look, you'll see that I did go to some length in the final paragraph to outline how I would deal with an error listing "StackHash_XXXX" as the faulting module.

 

@Paul--one thing that FSX does at shutdown that it doesn't do much of while running is write out a bunch of files (e.g. config files, last.flt etc). Sure sounds like something unhappy going on with your storage subsystem (controller chip, cables, SSD/HDD, and driver software), especially given the issue you're having with bootup. Do you have these problems with the system running at stock speeds?? Also, I consider a 24-hour Prime or OCCT burn-in and an overnight (8-10 hours) run of MEMTEST 86+ to be the minimum to consider a system long-term stable.

 

Regards

[flyingnoob 25]

ok, while having these other boot prio issues, i will leave the fsx issue on the back burner for now, although i greatly appreciate everyones help, - with any of the matters, i dont want my posts(or me) being responsible for any (bickering if i may) please by all means have differing opinions, and dont allow it to stop you from helping me out (lmfao).

 

I disco'd my 2nd ssd to try boot, so i will reinstall fsx if when i am ready, i did a cmos reset and reseated my ram(carefully with my leg firmly attatched to the radiator via copper wire).

 

Even the "stack errors" arent that big a deal (as long as i dont fry nothing) my next main isue was actually my pmdg not getting up to altitude) but as i said atm i am having a few issues and confusing myself as to where and what im posting.

 

 

I appreciate both your inputs, and if we can keep it in more laymans terms than - well laymans terms, then things should work out.

 

 

Kindest regards to both y'all.

 

Time for breakfast and yet another coffee

[Jim Young 2,356]

dont want my posts(or me) being responsible for any (bickering if i may) please by all means have differing opinions, and dont allow it to stop you from helping me out (lmfao).

 

Not a problem Paul. I apologize for going off topic. Everyone seems to be getting these StackHash errors lately but still, the only solution to this issue so far is to reinstall Windows and FSX. But if that doesn't fix it, then I would replace your RAM.

 

Best regards,

Jim

[flyingnoob 25]

Hi Jim, "replace"? as in warranty or change? the ram was on g.skills QVL with this mobo, - although it wasnt on asus's, it was on g.skills.

 

This mobo does have a compatibility button on the mobo, i will find out about that.

 

Dont worry about going off topic, it all seems relevant to me, so wasn,t really off topic

 

Regards

 

Paul.

 

Hi Jim - going by

My led very very breifly goes on when first powered up, but stays off during boot up and when its on.

Also when overclocked @4.7 with my ram manually set to 2400 its prime stable(ok its only 4 hrs, but thats all i tested) and its memtest fine 7 passes(i hear what you are saying bob )

I have no choice but to reinstall windows again i think, this time i will do it with only 1 ssd plugged in.

 

I cant believe there are very few of us that have this board and 2 ssd's installed that others can't chip in with their experience.

 

I'm sure "i'll be back!".

 

Kind regards

 

Paul

[Bob Scott 7,795]

I have a couple more thoughts for your problem Paul. Are both SSDs running in AHCI mode on the Intel ICH10 controller? Plugging the boot drive into a secondary (i.e. JMicron JMB362) drive controller on the mobo might be a problem (many mobos have three or even four different storage controllers on the board--which one you're using depends on which SATA connector the device is connected to). Also, make sure to install updated drivers for the secondary HDD controllers, even if there are no devices currently connected to them. I find it best to go to the chipset manufacturer (i.e. Realtek, JMicron etc), as the drivers on the mobo manufacturers' sites are often several versions out of date.

 

Also, since this is a new build, go to the support.microsoft.com website and run the latest DirectX update, plus the latest versions of the MS Visual C runtime redistributables for the 2005, 2008, and 2010 versions and install them in that order. Several years ago there was a problem with one of the MSVC 2008 versions that did not play nice with the 2005 version. Usually, if you have installed any recent software that uses the MSVCRT redistributables, the latest versions will have been installed in due course. But as more and more of us build dedicated FS machines and install our ancient software on them (FSX is now 7 years old), it's possible to build up a system and have some of the old long-fixed problems coming back for a second run at our sanity.

 

Regards