Need ideas on something I've never seen before

Departing KPVD and flying down Narragansett Bay I get this CTD:

Problem Event Name: APPCRASH

Application Name: fs9.exe

Application Version: 9.1.0.40901

Application Timestamp: 4135a208

Fault Module Name: StackHash_9b43

Fault Module Version: 0.0.0.0

Fault Module Timestamp: 00000000

Exception Code: c0000005

Exception Offset: 74ffc9f1

OS Version: 6.1.7601.2.1.0.256.48

Locale ID: 1033

Additional Information 1: 9b43

Additional Information 2: 9b431b0c90e83ec68d3d9c2ff7e024e8

Additional Information 3: feb7

Additional Information 4: feb7fc1b4ccfe33f19ad35c220a990e4

In exactly the same location every time I try it. Curiously and perhaps related to this is that if I enable

MissingLibraryAlert=1, I get a long list of missing files with names like:

0xcb4co364 - can't figure out what these files are or where they come from. Any ideas on that?

I have lots of add on sceneries in the area including FlightZone PVD, Westerly Airport, KMVY, Long Island Coastlines, New London, etc. I've tried disabling all the sceneries in the area and still get the stackHash CTD. I am really puzzled by this. I found a possible solution on the web involving DEP disabling for FS 9 but I had no joy after implementing. Still got the stackhash CTD.

I'd appreciate any suggestions on this. I've never had a problem as stubborn as this one in almost 20 years of flightsimming.

Incidentally, if I depart PVD to the West instead of South, no problem, no CTD.

I'm running Win7 Pro, GEPro, UT, UT2, REX, ANE on an I7 4.5, Titan GPU not oc'd, 8 gig memory.

Thanks in advance

Update: I tracked the problem down to one particular scenery which when loaded, caused the crash. And, it turns out there was an update issued by the author which I did not have. Soooooo, all is well.

I had a very similar thing happen to me yesterday after I had installed a freebie airport. By a process of elimination I traced the problem to a rogue .bgl file and deleted it. Doesn't seem to have had any effect on the scenery and the sim works OK again.

Dijvid

"0xcb4co364" sounds like a memory address; but if it's listed a a missing file it sounds like a name for custom textures, such as used by some of the larger texture replacers. A quick search of my FS9 folder and scenery folder (on different drives) found nothing by that name, so it's not part of GePro, UT, REX, VOZ, or Zinertek.

OTOH, if it is a memory address, and you get the exact same message for each CTD, it's possible you have a faulty RAM stick. Swap the RAM between the sockets and see if either the error goes away or you get different numbers.

Looking past scenery, does this happen with any aircraft at that point? There is a rare but known bug in FS9 which will cause a CTD with a particular aircraft in a particular direction over or near particular scenery. In my case it was an Italian WWII recon aircraft flying south over Tokyo Bay; I could fly this plane anywhere else in the world with no problems, even fly it north, east, or west over Tokyo Bay without issue. Disabling all add-on scenery in the area didn't help, fly south over the bay - CTD. (Researching this lead me to a couple of threads at FSDevelopers discussing the issue, though no one had any idea of the cause, or a solution ...other than "don't fly there in that plane".)

Thanks everybody for your thoughts. I learned a lot from this. I finally tracked the problem down to one particular scenery which when loaded, caused the crash. I just disabled all add on scenery within a hundred miles or so of the crash, and found the culprit by adding them back one at a time. And, it turns out there was an update issued by the author which I did not have. Soooooo, all is well.

I'm still puzzled by the missing library files. As jgf said above, a search of my entire two hard drives revealed nothing remotely resembling the file names. They do indeed sound like an add on file type but, no blood, no foul, so I just disabled that MissingLibraryAlert=1 line in .cfg and went happily on my way. Can't see where that had anything to do with the StackHash crash. I also searched the FS9 discs and couldn't find anything like them. They sounded a bit like CD scenery files but I could find nothing close.

Last edited by silverheels2

I'm still puzzled by the missing library files.

Last edited by silverheels2

From generic programming principles: When a program opens a file, it opens it by name which create or obtains something like a file pointer or a file descriptor. The name or number of other identifier of this pointer thingy is generally not human-meaningful. From that point on, the file name is no longer relevant, because all work on that file is then done via the pointer thingy. So a subprogram, particularly if it's in another file, such as a library, only gets this pointer thingy, and may not even know the associated file name. So if the file is missing, or there is a file processing error, then the error reporting can report only what it knows, which is that meaningless identifier.

Also, that number could be an offset or other identifier within the file, rather than the file itself. Or it could be a part of the GUID of a missing object. Or the last valid file location reference. Any number of things are possible. Error reporting can be very cryptic, particularly in the case of things that are missing. It is designed for the programmer to help fix the error, and so needs to be meaningful only to him, not to us mere mortal end users.

The bottom line that I see here is that you don't need to be too concerned about not understanding hex number error messages.

Steve from Mudgee

From generic programming principles: When a program opens a file, it opens it by name which create or obtains something like a file pointer or a file descriptor. The name or number of other identifier of this pointer thingy is generally not human-meaningful. From that point on, the file name is no longer relevant, because all work on that file is then done via the pointer thingy. So a subprogram, particularly if it's in another file, such as a library, only gets this pointer thingy, and may not even know the associated file name. So if the file is missing, or there is a file processing error, then the error reporting can report only what it knows, which is that meaningless identifier.

 

Also, that number could be an offset or other identifier within the file, rather than the file itself. Or it could be a part of the GUID of a missing object. Or the last valid file location reference. Any number of things are possible. Error reporting can be very cryptic, particularly in the case of things that are missing. It is designed for the programmer to help fix the error, and so needs to be meaningful only to him, not to us mere mortal end users.

 

The bottom line that I see here is that you don't need to be too concerned about not understanding hex number error messages.

 

Steve from Mudgee

Thanx Steve. That does make sense. And not worrying is good advice, now that the stackhash crisis is past. :}

The MissingLibraryAlert=1 will force FS to warn you when a scenery object is being called for and FS cannot find it.

The only info FS has about the object, other than where it is supposed to go, is the Global Unique ID number (GUID).

GUIDs are 32 place hexadecimal words. The warning gives you the GUID, broken into 4 sections, with each section having a leading 0x.

It is not a memory address, even though it kinda looks like one.

The only way to determine what that object is involves first determining, by process of elimination, what addon is calling that object. Then you have to determine what file in that addon is calling the object.

Once you know that you might be able to track down a missing library called for in the readme or contact the developer and see if they can help.

Good luck with the second option if the addon is not a recently released one.

Also note that you will get these warnings from default scenery as well.

I once built a bright pink building in Sketchup that was 50x50x1000 meters in size. I would then assign it the missing GUID and compile it to an object library .bgl so I could see in the sim where it was supposed to go.

I found one in FS9, in Ohio if memory serves, that was a missing construction crane. The base was where it was supposed to be yet the crane was MIA. Turns out that there was a typo in the object placement .bgl, one letter of the GUID was wrong.

Long story short, I ended up spending an hour or two tracking down something that many other simmers have probably flown over and not realized was missing.

Other than the satisfaction of solving a puzzle, it was a pretty hollow victory.

Most of the time that warning is more of an annoyance than anything.

peace,

the Bean

Bean, your pink building story was worth reading purely for entertainment alone! As well as being a great idea.

Steve from Mudgee

Bean, your pink building story was worth reading purely for entertainment alone! As well as being a great idea.

 

Steve from Mudgee

Great diagnostic method :)