simply that the P3D message may convey something - I didn't know if you looked at it. If you will, i'm simply obtaining a shortlist of eliminations that i'm not sure you checked. It's a normal process, so sorry if it might appear a waste of time.

Even so, that's dxdiag. But you are sure crashing P3D is the same result - namely subsequent runs of dxdiag or P3D work without crashing.

I don't suspect it, but 'clean as a whistle' might mean that all the stuff in there is OK, but doesn't show missing associated devices for the HIDs. I think that's OK or some message would appear during setup maybe.

I think you said something like only when connected and FSUIPC was running and not otherwise. Can try the controller assigned without FSUIPC? If so - still crashes?

Hi Ray, if everything fails, would it be possible for you to revert back your OS to factory settings to put your PC in the state right after you purchased it, where you didn't have the error?  After doing so, you could prevent W10 from updating to 1809. (You mentioned that everything is fine with 1803).

Edited December 1, 20187 yr by Afterburner

If what Ray says is correct, there may be more to it yet, but i'm beginning to wonder that something got installed in an odd way, which has led to confusion in the WinSxS. The crashed session leads to a second side by side session which now works.

Have a quick scan at the installed apps (Add/Remove) in Control Panel and check anything DX, .NET and C++ libs look OK, nothing odd there?

Edited December 1, 20187 yr by SteveW

8 hours ago, SteveW said:

I think you said something like only when connected and FSUIPC was running and not otherwise. Can try the controller assigned without FSUIPC? If so - still crashes?

Tests already done. The FSUIPC log showed P3D crashes during the initial joystick scan.  Ray told me it didn't crash with only P3D, no FSUIPC, but only with P3D set to read controllers in "raw" mode. If he switched to "directinput" mode, the same crash (in NTDLL) occurred. To us this suggested a DirectX problem, as the "raw" mode bypasses that and uses direct HID device access -- much like FSUIPC HID provisions in its Lua com library.

That's why he started using DXDiag.

Both the DXDiag and NTDLL crash reports showed error 0xC0000374, which I think is stack overflow.

And it didn't happen with Win10 1803. I am still on 1803 too and tried here without problem.

Pete

 

Edited December 1, 20187 yr by Pete Dowson

8 hours ago, Afterburner said:

Hi Ray, if everything fails, would it be possible for you to revert back your OS to factory settings to put your PC in the state right after you purchased it, where you didn't have the error?  After doing so, you could prevent W10 from updating to 1809. (You mentioned that everything is fine with 1803).

I tried reverting a few days ago but you only get a certain amount of time after which reverting isn't an option. Microsoft pointed me to a Media Creation Tool which rebuilds Windows into a clean state. That didn't work either. But that was to 1809, not 1803.

So much has happened in the 3 weeks since I got this PC it's hard to be certain that P3D was running cleanly. It was crashing when I was trying to run with MyTraffic6 and perhaps those crashes were down to DirectInput rather than MT6. The resultant error - ntdll.dll - seems to apply to all crashes irrespective of what the cause was.

8 hours ago, SteveW said:

I don't suspect it, but 'clean as a whistle' might mean that all the stuff in there is OK, but doesn't show missing associated devices for the HIDs. I think that's OK or some message would appear during setup maybe.

I think you said something like only when connected and FSUIPC was running and not otherwise. Can try the controller assigned without FSUIPC? If so - still crashes?

But if Device Manager shows nothing wrong why consider it suspect? Like P3D, FSUIPC, ChasePlane and even the GoFlight module are all victims of the problem, not the cause. The fact that I can run dxdiag, it crashes, and on a second run works correctly is key. After that P3D with all the associated programs in exe.xml and dll.xml run fine proves that.

7 hours ago, SteveW said:

Have a quick scan at the installed apps (Add/Remove) in Control Panel and check anything DX, .NET and C++ libs look OK, nothing odd there?

I will in the next hour. It would be a surprise though. If the crash report ffrom dxdiag doesn't provide a clue then I fail to see the point of providing the one for P3D. It's ntdll.dll which is so unhelpful even Microsoft couldn't tell me what the problem was. Makes you wonder what purpose they serve.

But the question that no-one, including Microsoft, appears to know the answer to is if dxdiag fails on its first run why does it work okay on a second when nothing has changed?

I just joined in this thread and I haven't read the majority of the previous posts.
So maybe I shouldn't interfere, nevertheless I noticed in your signature you have overclocked your CPU to 5.0. 
Is it an idea to run your CPU initially at stock speed and take it from there? 
In the past I also overclocked my systems only to discover it caused all kinds of havoc.

 

 

Edited December 1, 20187 yr by Egbert Drenth

Egbert,

The 8086K is designed to run at 5.0Ghz. It’s a professionally build system and P3D runs fine once the DirectInput problem is resolved. No BSODs, no lockup’s. Overclocking is not the problem I’m afraid.

Some encouraging progress. Unplugged all GoFlight modules, Saitek yoke and throttles and CH pedals. Only USB device enabled is keyboard / mouse.

Booted up and ran dxdiag. Ran cleanly. Rebooted twice more and on both occasions dxdiag ran cleanly.

It points to a suspect USB device. I'll connect them one at a time and take it from there.

This is indeed a strange problem. Each USB device when plugged in and dxdiag is run works okay. But when you add multiple devices dxdiag crashes.

Something Pete mentioned... " Both the DXDiag and NTDLL crash reports showed error 0xC0000374, which I think is stack overflow.

All I can do is report this to Microsoft and see what they say. But why doesn't the stack overflow when dxdiag is run a second time?

Here's the latest crash report...

Log Name:      Application
Source:        Application Error
Date:          01/12/2018 11:42:24
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      CHILLBLAST
Description:
Faulting application name: dxdiag.exe, version: 10.0.17763.1, time stamp: 0x08226207
Faulting module name: ntdll.dll, version: 10.0.17763.1, time stamp: 0xa369e897
Exception code: 0xc0000374
Fault offset: 0x00000000000fb349
Faulting process ID: 0x3288
Faulting application start time: 0x01d4896aeb0e1d40
Faulting application path: C:\WINDOWS\system32\dxdiag.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: b66efaf4-5063-4560-9c07-bbd8fbb52884
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2018-12-01T11:42:24.557520000Z" />
    <EventRecordID>1020</EventRecordID>
    <Channel>Application</Channel>
    <Computer>CHILLBLAST</Computer>
    <Security />
  </System>
  <EventData>
    <Data>dxdiag.exe</Data>
    <Data>10.0.17763.1</Data>
    <Data>08226207</Data>
    <Data>ntdll.dll</Data>
    <Data>10.0.17763.1</Data>
    <Data>a369e897</Data>
    <Data>c0000374</Data>
    <Data>00000000000fb349</Data>
    <Data>3288</Data>
    <Data>01d4896aeb0e1d40</Data>
    <Data>C:\WINDOWS\system32\dxdiag.exe</Data>
    <Data>C:\WINDOWS\SYSTEM32\ntdll.dll</Data>
    <Data>b66efaf4-5063-4560-9c07-bbd8fbb52884</Data>
    <Data>
    </Data>
    <Data>
    </Data>
  </EventData>
</Event>

I am just going to have to live with this until a solution is found.

1 hour ago, Ray Proudfoot said:

Something Pete mentioned... " Both the DXDiag and NTDLL crash reports showed error 0xC0000374, which I think is stack overflow.

Actually, that was from memory, and probably isn't correct.  It doesn't appear to be listed in the MS system error codes list (many aren't, annoyingly), but other references on the 'net saeem to agree that it is "heap corruption" -- presumably heap segment links are wrong (otherwise I don't see how that error can be detected).

Not that this distinction is very helpful I'm afraid.

Pete

 

2 hours ago, Pete Dowson said:

Actually, that was from memory, and probably isn't correct.  It doesn't appear to be listed in the MS system error codes list (many aren't, annoyingly), but other references on the 'net saeem to agree that it is "heap corruption" -- presumably heap segment links are wrong (otherwise I don't see how that error can be detected).

Not that this distinction is very helpful I'm afraid.

Pete

Do you not think it's a big clue Pete? Too much data to be stored with multiple devices but okay with fewer or one depending on what it is. And a second attempt is successful because the memory storage has changed.

I've never had a second run of dxdiag that failed. Anyway, I've reported it to Microsoft. I've had this kit for over 5 years on a Windows 7 PC and never had a dxdiag crash. It's only happened now with Windows 10. It has to be a bug in Windows.

15 hours ago, Pete Dowson said:

Tests already done. The FSUIPC log showed P3D crashes during the initial joystick scan.  Ray told me it didn't crash with only P3D, no FSUIPC, but only with P3D set to read controllers in "raw" mode. If he switched to "directinput" mode, the same crash (in NTDLL) occurred. To us this suggested a DirectX problem, as the "raw" mode bypasses that and uses direct HID device access -- much like FSUIPC HID provisions in its Lua com library.

That's why he started using DXDiag.

Both the DXDiag and NTDLL crash reports showed error 0xC0000374, which I think is stack overflow.

And it didn't happen with Win10 1803. I am still on 1803 too and tried here without problem.

Pete

 

OK. Thanks Pete. Have you seen the same error on other PCs with the same Win Update as Ray?

ntdll.dll and errors like stack overflow are going to come in with any problem encountered in that side so I wouldn't look too much into those in these circumstances.

As far as it seems from the thread here that there is no evidence that this is a Windows problem per-se. Could be as I mentioned a problem of part updated when something got installed.

 

So 'any two' devices in the USB system make the one time crash then next go they all work nicely Ray?

The multiple devices situation does still point to the problem I mentioned whereby the first session error allows the next session to run ok. I would need hands on to really to look at that.

Did something install any DX drivers and other libraries? The Win10 install should be already up to speed without any additions, more or less.

Did you try re-install all the controller setups again? After a clean boot with freshly powered up USB hubs and PC?