A fine start..

[Airspeed]

Dave
In my experience, you can't rely on MS messages. They never(?) describe the error in plain English, and most often are misleading.

Now, are you sure that you haven't inadvertently asked W7 to run these checks on start up? Does it happen every time you start, or only once a day? Or does it skip days?

Did you do that unplug and re-seating of your cards as suggested by Ro? As mentioned in another thread, my weird shut downs and boot fails stopped as soon as I moved my video card to a new slot.

I hope that you do not have to delve into that BEX thing; here's a mumbo jumbo that popped up when I looked:

CoreSight Program Flow Trace Architecture Specification PFTv1.0 and PFTv1.1
Home > Tracing Exceptions > The different exception cases > Exception occurs immediately after another exception
5.2.3. Exception occurs immediately after another exception

If two exceptions occur back-to-back, without the processor executing any instructions between them, then the PTM traces each exception with an exception branch address packet, without any waypoint update packet between them. In the trace stream, an exception branch address packet occurring immediately after another exception branch address packet indicates that one exception occurred immediately after the other.

For example, consider the case where an FIQ interrupts an IRQ:

When the IRQ occurs, the processor updates R14_irq with the exception return address and switches to IRQ mode.

The FIQ occurs before the processor has fetched the instruction from the IRQ vector. Therefore, the processor updates R14_fiq with the IRQ vector address and switches to FIQ mode.

The processor fetches the instruction at the FIQ vector and branches to the FIQ handler.

The FIQ handler returns to the IRQ handler as if it was a normal branch. Therefore, for execution up to the entry to the FIQ handler, the PTM must generate a trace stream that indicates that both exceptions occurred, without any instructions being executed at the IRQ vector address. Table 5.3 shows how this is traced.

Table 5.3. Tracing back-to-back exceptions
Address Instruction Trace, if any, with explanation
0x1000 MOV Nonwaypoint instruction. Not traced when processor executes the instruction.

[DaveB]

That means about as much to me as it does to you Mike

No.. the checkdisk malarkey has only just started happening. Once last week and again this morning. It's never done it before over the life of this pc. As for System Maintenance.. I've never seen that before

The error in FSX was after I'd shut down rather than the more common variety (as I've since read) which happens as you start FSX. I can't remember ever having an error at the start. Whatever has happened with FSX in the past is after I've closed down and the usual culprit there is ai.player.dll. I've since renamed all my default airliners so the FSX traffic file doesn't find them which enables me to 'use' the Airliner traffic slider to some degree without getting the ai.player.dll error on closing (after FSX has shutdown to all intents). There is always a moment after shutdown when the sim has cleared from the main screen but remains visible on the taskbar. After a few moments.. FSX finally lets go and it goes. If the delay is longer than a few moments.. it is usually accompanied by an error.. generally, ai.player.dll. Since renaming the default airliners.. this error is rare.

I've not had the side off yet. I don't expect the cables to be loose as they're all the clip-in variety (rather than push in with no clip) but I'll do this tomorrow.. time and schedule permitting

Never seen BEX before and I had to 'Bing' it to find out what it was.. not that I knew much after!

EDIT: Looking at when I first posted this, it was a Tuesday and today is Sunday so there's nothing 'regular' about CHKDSK or System Maintenance running. I've pulled the sides off and checked the HD cables.. all as tight as a nun's habit

ATB
DaveB

[rohan]

Guys,
as far as BEX and other shutdown errors are concerned, they could be generated because of the age of FSX. By that, I mean that we're all running s/w that is around 8 years old in an o/s that is 4 or 5 years old but which is set up to run in 2014. While it's good to always have your environment up to date, that environment (o/s subroutines, .NET functions, etc.) is called by and supports the functions that FSX needs to run. Every now and then, because m$'s test and QA facilities don't cover all apps in use today, older function calls from something as old as FSX can't or won't necessarily work properly in all cases. The most persistent problem caused by this situation was a tendency to sometimes report an error along the lines of "the memory at xxxxx could not be written to" when a programme was shutting down - meaningless but worrying. The monthly o/s updates will often be the immediate cause of both an error suddenly appearing and just as suddenly disappearing.

Having said that, an error from FSX itself like those AI errors is just that - an FSX error - and hence is something that the user can probably do something about, if they have sufficient information or tools to use for diagnosis,
regs,
Ro

[rohan]

... I don't expect the cables to be loose as they're all the clip-in variety (rather than push in with no clip) but I'll do this tomorrow...

Ah, but a connection doesn't have to be loose to cause a problem. It's a good idea to actually unplug a cable and plug it back in to (a) make sure it's connecting properly, and (b) ensure the pins are making a good contact inside the plug and socket. In fact, depending on how long it was since they were first plugged in, it may be worth unplugging and replugging a cable a few times. That's why we talk about re-seating a card, and I should have said re-seat when talking about the cables too ...

regs,
Ro

[DaveB]

Thanks Ro Sri for the late response.. just got in from work

Regarding BEX.. understood. In isolation, I wasn't too fussed by what FSX can throw up. As I understand it.. ai.player.dll is one of the first things to let go though it can be caused for a number of reasons. In my case, through trial and error.. I found that having airline traffic cranked up, the error was more likely to occur. With it much reduced or indeed, turned off.. the error never occurs. APPCRASH is one I've seen before too though not often. BEX is just another for the list

ATB
DaveB

[Airspeed]

Dave,
I remember during the 1970s, a visitor had a seemingly flat car battery.
We looked under the bonnet and couldn't budge the battery terminals.
Assumption was that the connection was good.
WRONG.
After exhausting ourselves trying to push start him, we finally unbolted the terminals, cleaned and refitted them.
You guessed it, started first try.
We also had a TV that was off-air for years. One day, I pulled the connection off the back of the CRT, then pushed it back on.
Worked again.
As I read it, you've inspected the connections. What Ro and I are suggesting, is to remove the cards and cables, then refit them.
No promises, but it's a hell of a lot easier than endlessly chasing possibly non existent software faults.

[Vc Ten]

Thought I would check out world of ai this morning just to see if anything new There was a recent timetable for Easy jet so deleted the existing one in the sim and installed the latest version Two flights later and both times fsx has closed with appcrash. ai player.dll Never seen it before as fsx always shuts down cleanly. I've deleted easy jet for now and a quick test showed it closed fine
Atb
Dale

[DaveB]

Yes mate.. WOAI and MAIW plans are often the cause of ai.player.dll errors. Always good policy to check them out with AIFP then recompile just to make sure. I made a mistake a couple of weeks ago by installing 3 MAIW plans due to the absence of statics at Coningsby (which a later re-install of VFR Airfields part3 fixed). After installing the plans.. Coningsby was full of Typhoons and Tonka's but.. all my other AI had disappeared. They were FS9 format

ATB
DaveB

[J0hn]

Talking briefly of AI - yesterday I had a couple of flights from Brize Norton and was using VoxATC.

Whilst I was very unimpressed by having to wait at the holding point for nearly half an hour ( ) I was very impressed by the activities going on with the AI aircraft. C-17s, VC-10s and Hercules, mostly - with two even visiting from Holland. Mind you - mixing Cessnas with them was a bit off!

I started getting lock-ups and errors with FSX now, too. Mine started after that beast called Java insisted on uninstalling my v7.8 and installing v8.

[DaveB]

Ah yes.. let us not forget the evil program that is JAVA.. written by Satan himself (or more likely, herself!)

Since getting the second CHKDSK on Sunday, it's run ok.. the PC that is. I got that BEX error on FSX but put that down to a one-off. Having been happy to let SpyHunter4 check for bugs (this a revised version.. the previous one caused stop errors when closing Windows).. I downloaded the trial version of Malwarebytes yesterday and ran that. It found 3 references to bubble-dock and quarantined them which would be fine were it not for the fact that I bought SpyHunter to get rid of it and it reportedly had! Now.. whether MWB found SpyHunter quarantined 'instances'.. I don't know. The ref didn't look like it was associated with SpyHunter in anyway (it was in TEMP) but I can't be sure. I've never been keen on running multiple instances of 'bug removal' progs in case they start fighting

ATB
DaveB