Unfortunately its still not working for me. Just ran my test flight again in the MD-11 from EGLL and LSZH as per the tutorial. This time I had set sound quality to 0 in the CFG file. But when I landed at LSZH I brought up the Map from the Menu, then as soon as I return to the sim the display was corrupted. Interestingly though this time I didn't get flickering, I just ended up with a blue sky, with no clouds, no ground textures and no scenery objects, also the VC has disappeared. Moving to the external view all I could see apart from the blue sky was the external engine casings for the 2 wing engines (tail engine not visible) and the Landing Lights (floating in mid air!). Apart from that everything was missing.I really hope someone from PMDG picks this thread up again as I only get this problem with their planes, and only since I upgraded to a Core i7. I had the exact same Operating System and spec before, just running on a Q9650.Its a real shame as i love the PMDG planes but this is really starting to put me off. I don't think I'd purchase another one until I can solve this problem (or a guru from PMDG helps solve it!)Rob

Rob sorry to hear about your troubles & know how frustrating and quirky FSX can be. I'm sure the folks over at PMDG have gone partially bald attempting to come up with a solution as more customers modernize their OS platforms. With SOUND_QUALITY=1 I had another uneventful flight; this time JFK - SAN in the -8i . Its worth noting that I am using another user's (sorry drawing a blank on the name) tweak in which a proper sound device (rather than default) is selected from the FSX sound GUI. I absolutely punished my system throughout the flight exiting full screen, switching between apps and surfing IE8 attempting to force an error. The sim would have none of it, and performed flawlessly. For the record I don't use bufferpools or affinity masks. In fact, my system is set up as recommended by Nick over in the GEX forum with Autogen at Dense and no aircraft self shadowing. I'd like to string a few more medium to long haul flights before declaring victory, but the trend seems to be going well. I've been eyeing the Sager 9280 notebook with the desktop i7 960 for my FSX road rig but haven't pulled the trigger because the bios isn't XP64 compliant.

Rob sorry to hear about your troubles & know how frustrating and quirky FSX can be. I'm sure the folks over at PMDG have gone partially bald attempting to come up with a solution as more customers modernize their OS platforms. With SOUND_QUALITY=1 I had another uneventful flight; this time JFK - SAN in the -8i . Its worth noting that I am using another user's (sorry drawing a blank on the name) tweak in which a proper sound device (rather than default) is selected from the FSX sound GUI. I absolutely punished my system throughout the flight exiting full screen, switching between apps and surfing IE8 attempting to force an error. The sim would have none of it, and performed flawlessly. For the record I don't use bufferpools or affinity masks. In fact, my system is set up as recommended by Nick over in the GEX forum with Autogen at Dense and no aircraft self shadowing. I'd like to string a few more medium to long haul flights before declaring victory, but the trend seems to be going well. I've been eyeing the Sager 9280 notebook with the desktop i7 960 for my FSX road rig but haven't pulled the trigger because the bios isn't XP64 compliant.

Thanks for your help Ryan. I took your advice today and changed the Sound settings from "Default Primary Device" to my actual sound card. This seemed to do the trick for a bit. I managed the flight in the MD-11 from EGLL to LSZH without a problem - even accessing the Map etc. However on the return flight back to EGLL the flickering/missing VC cockpit problem occurred again after I opened the map. Interestingly though I hit Alt-Enter and in windowed mode the problem went away. However when I dragged out the window to make it larger the flickering/missing VC occurred again.This sure is a puzzler!!

Thanks for your help Ryan. I took your advice today and changed the Sound settings from "Default Primary Device" to my actual sound card. This seemed to do the trick for a bit. I managed the flight in the MD-11 from EGLL to LSZH without a problem - even accessing the Map etc. However on the return flight back to EGLL the flickering/missing VC cockpit problem occurred again after I opened the map. Interestingly though I hit Alt-Enter and in windowed mode the problem went away. However when I dragged out the window to make it larger the flickering/missing VC occurred again.This sure is a puzzler!!

What system hardware is handling sound? I ask because removing my SB XFi and using onboard MB sound has helped me in three areas. First it eliminated EFIS screen freezes while in VC on the whale and the MD11. Second it allowed me access to a full range of W7 sound bitrates that were simply unavailable through the SB driver set. Lastly, it has been the most effective remedy in minimizing or (in my case) potential permanent eradication of the corrupted texture issue. Perhaps it is the combination of lowering your sound bitrate in W7 / Vista AND the lowering of sound quality in the FSX cfg that bears fruit?

I just experienced display freezing in the virtual cockpit the last 2 flights. Before I used to be able to just press A to go back to the 2d panel then a again to the vc, but it doesn't fix it now... Everything else runs great though. This is annoying

I just experienced display freezing in the virtual cockpit the last 2 flights. Before I used to be able to just press A to go back to the 2d panel then a again to the vc, but it doesn't fix it now... Everything else runs great though. This is annoying

If you do not start signing your full name to your posts you're going to banned. This is not the first time you've been warned.

Since last weekend I have been experiencing CTD's/Black Screens/Corruption as well with the 747XI recall this happening before, but only occassionally. Now it will happen before I get the chance to take-off. But there is a difference. To me it is happening when I click on the Panel Switcher. I haven't seen it happen when I open one of the smaller panels, but sooner or later opening the overhead panel, the FO or the captain's view will cause a crash.Last Sunday I cleaned up all traces of FSX and reinstalled, but the problem is still there.My setup is:HW: ASUS P5E, E8400, 4GB, 8800 GTS 512 MBOS: Windows XP 32, SP3 (Dual boot with Vista 64, not using that for FSX)FS: FSX Acceleration, MyTrafficX, PMDG 747XAll other add-on's not re-installed so far. I've even unplugged the FS hardware I was using before (TrackIr, VrInsight MCP, Saitek Yoke), All sliders are at their lowest position, all features, filters, effects off, tried with/without nHancer. The crash will occur with the 747X/747XF, during day and night.I can handle a debugger, but because FSX is still blocking the screen I can't see my debugger (now that I think of it... that probably means it only happens in full screen). So last night I setup the remote debugging stuff from Visual Studio and attached to FSX from a remote computer. After loading the 747X I just had to click a while on the panel switcher and sooner or later FSX would crash (sometimes preceded by some corruption).The remote debugger did show me the callstack and the crash always happens at the same location, inside msvcrt.dll. There is an access violation in the _memcpy function. So, looking a bit further I noticed the callstack is always the same, with the call to _memcpy originating from the DirectX call D3DXLoadSurfaceFromMemory, which is called from the FSX dll g2d.dll.I'm going to try to find out what is intended to happen in this piece of the program.Daniel van Os

Soundquality=0 sadly doesn't do the trick for me.Landed in LSZH everything ok but then on the apron, after switching between fullscreen and windows mode, textures of the MD11 disappear and later I got a black screen. :( I don't think it's nvidia related because you can read on several forums that ati users are also affected by this problem.Starting this flight in EDDF directly with the MD11 wasn't possible because I got texture problems soon after FSX loaded.I had to load aircreation trike first and then the MD11 but the end of the flight is described above......The flight was realized with no Bufferpools entry on a fresh fsx.cfg, I will try Bufferpools=0 but the past showed that there was no difference. The black screen also appeared with Bufferpools=0.Sincerely Mats Weinberger

Since last weekend I have been experiencing CTD's/Black Screens/Corruption as well with the 747XI recall this happening before, but only occassionally. Now it will happen before I get the chance to take-off. But there is a difference. To me it is happening when I click on the Panel Switcher. I haven't seen it happen when I open one of the smaller panels, but sooner or later opening the overhead panel, the FO or the captain's view will cause a crash.Last Sunday I cleaned up all traces of FSX and reinstalled, but the problem is still there.My setup is:HW: ASUS P5E, E8400, 4GB, 8800 GTS 512 MBOS: Windows XP 32, SP3 (Dual boot with Vista 64, not using that for FSX)FS: FSX Acceleration, MyTrafficX, PMDG 747XAll other add-on's not re-installed so far. I've even unplugged the FS hardware I was using before (TrackIr, VrInsight MCP, Saitek Yoke), All sliders are at their lowest position, all features, filters, effects off, tried with/without nHancer. The crash will occur with the 747X/747XF, during day and night.I can handle a debugger, but because FSX is still blocking the screen I can't see my debugger (now that I think of it... that probably means it only happens in full screen). So last night I setup the remote debugging stuff from Visual Studio and attached to FSX from a remote computer. After loading the 747X I just had to click a while on the panel switcher and sooner or later FSX would crash (sometimes preceded by some corruption).The remote debugger did show me the callstack and the crash always happens at the same location, inside msvcrt.dll. There is an access violation in the _memcpy function. So, looking a bit further I noticed the callstack is always the same, with the call to _memcpy originating from the DirectX call D3DXLoadSurfaceFromMemory, which is called from the FSX dll g2d.dll.I'm going to try to find out what is intended to happen in this piece of the program.Daniel van Os

I just got really excited. It seems like you have found the cause. Maybe you can find the fix? Thanks in advance for doing the hard work that some of us cant do.

I have been looking further into it. Yet yesterday I had a really hard time reproducing the crash. Before, within 25 clicks on the panel switcher the crash would occur. Yesterday... I took me a lot of clicks (daytime or windowed mode seem to inhibit the crash).The crash below was created by: loading flight with 747XF daytime, loading Cold and Dark panel state, switching time to Dusk, switching x times between Captain/FO/Overhead panels.The crash occurs somewhere down (or up :( ?) the callstack of this DirectX function:

HRESULT D3DXLoadSurfaceFromMemory(  LPDIRECT3DSURFACE9 pDestSurface,  CONST PALETTEENTRY * pDestPalette,  CONST RECT * pDestRect,  LPCVOID pSrcMemory,  D3DFORMAT SrcFormat,  UINT SrcPitch,  CONST PALETTEENTRY * pSrcPalette,  CONST RECT * pSrcRect,  DWORD Filter,  D3DCOLOR ColorKey);

My knowledge of DX is very limited, but from the docs it seems this function is used to copy a texture from 'computermemory' to 'displaymemory'. When the function crashes it is called with CubeSurface object as pDestSurface., destination palette and rect are not used (the latter meaning that all of the source texture should be copied). SrcMemory is a valid pointer and it could very well be pointing to texture data (at least it's not text, program code, empty, garbage). SrcFormat is 25 D3DFMT_A1R5G5B5, meaning: 16-bit pixel format where 5 bits are reserved for each color and 1 bit is reserved for alpha.Pitch is 0x1000 = 4096, meaning 4096 bytes per line of the texture (with a 16 bit pixel format that would be 2048 pixels per line)No SrcPalette is given.The SrcRect tells me the source texture is 2048x2048 pixels, which is a match for the format and pitch above.The filter is 1 (NONE) = No scaling or filtering and the ColorKey = 0 (disabled).So the size of the source texture = 2048x2048x16 bits / 8 / 1024 / 1024 = 8 MB.The crash happens when memcpy in msvcrt is reading from within the source texture and writing to the surface. At the moment of the crash only 105 lines of the source have been written, during the 106th line an attempt to write to unallocated memory is made.The hard part now is to get more information about the CubeSurface that is used as the destination, it should contain a description of the surface but I haven't been able to find it (the pointer is actually that of an interface and one of the methods in the interface is GetDesc and I have found that one but so far no luck on analysing how it retrieves the surface description).But... it seems a texture is copied to a surface, but the memory allocated for the surface is not large enough for the texture.If at the end of the memory for the surface there is other memory allocated, this will corrupt the data in the allocated memory.If at the end of the memory for the surface there is no other memory allocated, this will cause an access violation exception and crash FSX.The larger the source texture is, the more likely it is to corrupt other data or hit unallocated memory. Thus with more large textures inside FSX this is more likely to happen and probably a good way to get more large textures is installing high-end add-on's.There is a (very small) possibility that the problem is really specific in that it will only happen for 2048x2048 textures in D3DFMT_A1R5G5B5 format in which case avoiding these texture could be a work around, but probably the problem is more generic (avoiding the use of all textures might not be an option for everyone :( ). I'll have to analyze further and see if the source format is always the same when FSX crashes.Daniel van Os

**** Update on Cream Screen of Death ******Hi All,Just a quick recap........I have a dual boot system with Windows XP x64 (SP2) & VISTA x64 Home premium (SP2). I have FSX installed on both systems. Full system specs below.With XP 64 and using the PMDG MD-11, I get a cream/white coloured window after I use ALT-enter a few times (sometimes 3 times, sometimes 10 or so times).The sound keeps going & there isn't any texture corruption on the aircraft or scenery with this event. Sometimes you can recover, but most times you cannot recover the visuals.And now.......I have done a complete re-install of XP x64 (with SP2 included on the install disk) and set up FSX and the XP OS exactly as per NickN's procedure but the problem persists.The ONLY add-ons are the PMDG 747 & the PMDG MD-11.Does anyone have a fix for the cream/white coloured window problem??????Pete

Su no es bueno. After a short flight earlier today from ABQ-SNA I parked the MD11 and left the sim running through the dusk hours into twilight. After a few ALT ENTERS I finally received texture corruption. Evidently using the sound tweaks worked wonders in my system but performed no miracles. I suppose I'll boot over to XP64.

http://forums1.avsim.net/index.php?showtopic=271292http://forums1.avsim.net/index.php?s=&...t&p=1692080http://forums1.avsim.net/index.php?s=&...t&p=1693372John U.

I've been analyzing further... It appears harder and harder to reproduce the crash, so I started to look for something that has changed. And I found a variable: I'm using real world weather, so from run to run the weather can/will be different. From now on I'll use a fixed weather type to take that variable away as well.I have created a dump of the complete memory at the time of the crash and then used WinDbg to write the 8MB containing the source texture to a file. I then created a small app that would convert the raw 5 bit colour data to 'normal' rgb values and dumped the result to a bmp file. Here's the texture that is being copied (reduced from 2048x2048 to 400x400 by me)Now before you start accusing PMDG... the original image by PMDG is a 1600x1200 32 bit bmp, this is a 2048x2048 raw 16 bit image. So FSX has been processing this already.I have to lookup what a CubeSurface actually is and see if the contents of the image above make any sense from that perspective, but it seems something is wrong with the source already.I also encountered a different crash, this one occurred when switching from day to night. The crash happened inside some D3D cleanup calls, which still makes sense as probably the clean up got lost on corrupted memory.I think it is going to be very hard to get any further from here on. I'm almost certain that PMDG/NVidia/ATI are off the hook. Either FSX or DirectX is messing up. I could revert to FSX SP1 and see if that fixes the problem for me. But what would that tell me? 'Make sure you have updated to the latest DirectX' is a common suggestion, but FSX SP1 and SP2 are using fixed versions of DirectX (9.12.589.0 for SP1 and 9.19.949.46 for SP2). So if the problem goes away in SP1, is that because the bug is not in SP1 or not in DX 9.12?Daniel

The crash occurs somewhere down (or up :( ?) the callstack of this DirectX function:

HRESULT D3DXLoadSurfaceFromMemory(  LPDIRECT3DSURFACE9 pDestSurface,  CONST PALETTEENTRY * pDestPalette,  CONST RECT * pDestRect,  LPCVOID pSrcMemory,  D3DFORMAT SrcFormat,  UINT SrcPitch,  CONST PALETTEENTRY * pSrcPalette,  CONST RECT * pSrcRect,  DWORD Filter,  D3DCOLOR ColorKey);

Daniel, since you know what you are doing you might want to try this suggestion:YOU NEED to read carefully and follow the steps EXACTLY...1) Locate the ShadersHLSL inside your FSX folder.2) Now, locate the 'Common' folder inside ShadersHLSL3) You'll see a file called: Common.fxh Locate the following line in that file:dword State_TextureWrap : STATE_TEXTUREWRAP = D3DTADDRESS_WRAP;Now, LOOK CAREFULLY at the begining of the file... there is a declaration for D3DTADDRESS_WRAP which is:#define D3DTADDRESS_WRAP 1I've been testing the past two weeks a fix that 'seemed' to COMPLETELY eliminate the source of corruption and black textures, and I think it was due to Texture Compression of ALREADY compressed textures.. so I changed the line:dword State_TextureWrap : STATE_TEXTUREWRAP = D3DTADDRESS_WRAP;todword State_TextureWrap : STATE_TEXTUREWRAP = 0;REMEMBER, you need to delete the shaders cache (so it is rebuilt again using the above parameters) the shaders cache is located in:C:\Users\USERNAME\AppData\Local\Microsoft\FSX\Shadersyou need to COMPLETELY remove the Shaders directory and it will be rebuilt the next time your start FSX.Then, try again, you should not experience texture corruption anymore. Enjoy :)

Sadly this doesn't also work for me.Mats Weinberger