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;and change to:dword State_TextureWrap : STATE_TEXTUREWRAP = 0;REMEMBER, you need to delete the shaders cache directory (so it is rebuilt again using the above parameters) the shaders cache is located in:C:\Users\USERNAME\AppData\Local\Microsoft\FSX\Shaders if you don't delete this directory, the above change will be useless.The shaders cache directory will be rebuilt the next time your start FSX.

Another value that could prove helpful for some is MAX_BONES, right now I think its 22. You can play with that value increasing it a bit to 32 and test.

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 :)

By jove, he's (possibly, maybe) done it !I would encourage anyone with this problem to (1) undo all the bufferpools and sound fixes and (2) try this shader fix. So far, it's worked for me, including in my "stress test of death" scenario where up until now I have ALWAYS been able to guarantee a problem if the sound quality was higher than 8000Hz.If this fix is a keeper, then thanks *******.TimEDIT: Damn: just got one, after trying a test without a complete reload of the sim - but definitely a lot harder to trigger.

By jove, he's (possibly, maybe) done it !I would encourage anyone with this problem to (1) undo all the bufferpools and sound fixes and (2) try this shader fix. So far, it's worked for me, including in my "stress test of death" scenario where up until now I have ALWAYS been able to guarantee a problem if the sound quality was higher than 8000Hz.If this fix is a keeper, then thanks *******.TimEDIT: Damn: just got one, after trying a test without a complete reload of the sim - but definitely a lot harder to trigger.

Sorry to reply to my own post, but this is the first time I've made progress in a long while so please forgive my enthusiasm. For anyone with these problems, may I urge you to try this little combination:1. *******'s "shader" fix;2. These entries in the "[sOUND]" setting of the FSX.CFG file:SOUND_QUALITY=0SOUND_LOD=03. Under the "[bUFFERPOOLS]" setting:UsePools=0Set sound quality in Windows 7 / Vista back to normal, and give it a go.In my case, there have been two noticeable changes:(1) MUCH harder to trigger the black/ disappearing texture problem; AND(2) when / if it does eventually happen, I seem to be able to GET THE SIM BACK! To do this, wait a while, then press ALT+ENTER and see if the image comes back. If not, give it another short rest, then try ALT+ENTER again - and keep trying.Let us know what happens.Tim

1. *******'s "shader" fix;

Hi Tim,I think that this 'black screen' problem has multiple sources... the 'shader fix' simply compiles the new shaders using a different flag. Common.fxh its a HEADER file, you only see variables there. So, then you set the Texture Wrap to 0 you are just removing one 'possible' cause. But Video MEMORY exhaustion is another, and MEMORY LEAKS caused by add-ons one more! buggy sound drivers another one.. thats why there is no 'single' fix. The texture wrap seemed like a logic step, no rocket science there. The only problem with that fix is that is kind of 'dangerous' someone could get confused and delete the ShadersHDLR folder instead of the correct 'cached folder' inside AppData/Local

I will see what it does for me, thanks!Right now my impression is that there is a bug in FSX that eventually will corrupt textures/surfaces. This can lead to corrupted images on screen or access violations. Any update of the screen can trigger a crash once the corruption is there: opening a new panel, closing a dialog, reloading a flight. The larger the update and the larger the textures involved the more likely something goes wrong.Several tweaks and fixes have been proposed and since most of them appear to have at least some influence on how (texture) memory is handled I can see why they can affect the time it takes for the crash to occur.I think I will try FSX SP1 after all, just to see what happens. Of course there are many references to opening and closing menu's before the black screens and if I'm correct the menu handling was changed between SP1 and SP2.Daniel van Os

Right now my impression is that there is a bug in FSX that eventually will corrupt textures/surfaces. This can lead to corrupted images on screen or access violations. Any update of the screen can trigger a crash once the corruption is there: opening a new panel, closing a dialog, reloading a flight. The larger the update and the larger the textures involved the more likely something goes wrong.

I think you are correct... I do have a situation file that CONSISTENTLY failed at the exact time every single time.. so, It was a matter of trying different options to see 'what' affected its behavior. My only solution, was to run FSX in compatibilty mode (I run Win7) and was running Vista compatibility mode with great results.. however, this was not a 'solution'When I read your post, I started looking into the ONLY thing in FSX that actually changes DX behavior for shader/animations and the texture wrap setting caught my attention. I was surprised to find out setting it to 0 completely eliminated corruption in the situation file I consistently got problems. now, YOU ARE CORRECT assuming there are different sources! texture corruption can be due to a series of factors, this solution (disabling texture wrapping) does not address them all, but in my specific case solved my problem. FSX seems to get unstable ONCE it fails loading a single texture, so it *MIGHT* be possible a single texture (or set of textures) is causing problems for users... I think the very first step in trying to solve the problem completely is finding a test case scenario where (even with texture wrapping disabled) a corruption error can be triggered CONSISTENTLY, not randomly.. is someone can do this and Daniel debugs the situation, I think you might have a solution.Evidently, we don't know (yet) whats causing the corruption, for example.. Tim, even disabling Texture wrapping got an error! however, I can't, no matter what I do.. yet, I do not have any PMDG product installed, IF this can only be triggered with a PMDG product, then a SINGLE corrupted texture could be the culprit!!make sure you monitor your Video Ram usage.. you want to make sure you are not exhausting it!! this could ALSO be a problem.. GPU-Z does include a video ram utilization monitor, you can download it here:http://www.techpowerup.com/downloads/SysInfo/GPU-Z/and run it along with FSX to see how much video RAM it is using.

Hi there,tried out the shader and the buffer pool tweaks today, and they really almost eleminated the artefact/black screen problem on my rig and made my FSX very smooth, thanks a lot for that! But I could still recall it: Loading CS 727 at KSEA at daytime / alt-enter changing the screen mode / changing to dusk / alt-enter again.Then the AI planes and AP were only half-loaded. But always changing to 2D Panel View before alt-entering seems to do the trick for me. No Black screens or artefacts so far, still testing though. Also testet with the Simcheck A300, same result. Best Regards,Mike.

can somebody explain exactly what this shader tweak is step by step? I have win7 x64ThanksDavid Alexander

............3. Under the "[bUFFERPOOLS]" setting:UsePools=0 .........Tim

Tim,I don't use the [bUFFERPOOLS] entry in my .cfg file.Do I need to put it in?Also, is it UsePools=0 or Poolsize=0 ??I am gobsmacked that we seem to be making headway. Thanks to all who have tried so hard.Thanks,Pete

Tim,I don't use the [bUFFERPOOLS] entry in my .cfg file.Do I need to put it in?Also, is it UsePools=0 or Poolsize=0 ??I am gobsmacked that we seem to be making headway. Thanks to all who have tried so hard.Thanks,Pete

If you want to give this one a go, then you'll need to add a [bUFFERPOOLS] section. For this particular experiment, the only entry beneath it should be "UsePools=0". Tim

Just to add to this, here is an excerpt from Nick N's post on tweaking FSX:[bUFFERPOOLS]Poolsize=XXXXXXXX // 10000000 - 15000000 for 512MB cards, 35000000 for 640MB cards, 70000000 for 768MB cards and between 100000000 and 490000000 (100 to 490MB) for larger VM memory SINGLE CORE video cards. I have used bufferpools in the past and seen the difference, both positively and negatively, but my entry was Poolsize=xxxxxxx that I used.

It has nothing to do with Bufferpools entries, shaders or things like that.The problem is virtual address space.With largeaddressaware linker flag, FSX is able to address up to 3 GB of virtual address space under 64 bit OS.If you increase Lod-Radius or Max_Texture_Size for example (addons like REX increase texture size up to 4096 for HD clouds or McPhat UHDT liveries where texture_max_load has also to be increased up to 4096) there is a very heavy graphic load.Since Vistas WDDM1.0 the virtualization of video memory increases the amount of virtual address space that applications use.So if the maximum of virtual address space is reached you will get disapperaring textures or black screens.This explains why people with XP 64 bit are not affected by this problems because memory management is different to Vista and Win 7.Landing a PMDG aircraft on a big airport in bad weather conditions or darkness is much more video load as landing a cessna on a grass runway.So increasing in addition more video load by tweaking fsx.cfg as described you will run out of virtual address space limits.Mats Weinberger

OK, but if this problem all comes down to virtual memory management where does the fault lie,in the sim core code? Seems like there should be a way to gracefully handle it, right? After allthats what VM OS design has been about for the last 3 decades :)And if, as I tend to agree, this is the underlying issue, how do we handle it now so we avoid thesepainful symptoms??Cheers,

OK, but if this problem all comes down to virtual memory management where does the fault lie,in the sim core code? Seems like there should be a way to gracefully handle it, right? After allthats what VM OS design has been about for the last 3 decades :)And if, as I tend to agree, this is the underlying issue, how do we handle it now so we avoid thesepainful symptoms??Cheers,

The problem is not a lack of virtual memory for every user that experiences these issues. Virtual memory deprivation is easily measurable using Windows tools or Process Monitor. The memory issue is most likely to affect people using a 32-bit operating system. However as Mats indicates Vista and W7 have different memory management strategies than XP and due to these different strategies even Vista 64 or W7-64 users can experience issues but not all do. This issue is virtually non existent in XP-64.Speaking to 32-bit versus 64-bit operating systems in general and not related specifically to FSX. The issue in 32-bit code is that it was once thought we would never exceed the 4GB memory limit. New programs today are easily exceeding the former 4GB limit, as we learned even FSX with add-ons is very easily capable of exceeding these limits. For people on 32-bit systems the answer is to move to 64-bit systems. If you must stay on a 32-bit system apply the 3/GB switch or userva command for Vista/W7 users. Even with a 64-bit system FSX is in need of updating which will never likely happen since Aces is no more. Question now is will Microsoft ever address the memory management strategy in Vista or W7 so that it can play nice with FSX. Regardless of any updates for Vista or W7 32-bit systems, a 32-bit system will never be sufficient for FSX and a switch to a 64-bit system will be in order. You simply cannot make a 32-bit system act like a 64-bit system due to the differences in code short of rewriting the entire system which in effect was what was done in the writing of 64-bit code. The current best solution is to run FSX with XP-64, followed by running FSX with W7-64 and if running W7 hope you do not experience the issues that the people in this thread are experiencing.

Sorry. been there done that :)I ran XP-64 before even Vista came out, and its anything but the panacea that thisthread is making it out to be. It had LOTS of little quirks and burps of its own. WhenI first switched to Vista Ultimate 64, (again a couple years back) it was a BIG improvement.Now I ran Win 7 Ultimate.The whole 32 vs 64 thing gives me giggles, I've been a Unix software engineer for 25 years,and we were pushing beyond the 32 bit boundary back in the 90's, as usual Microsoft comesalong late and convinces the herd they did something "revolutionary"... uhuh :)Oh, and to answer some questions belatedly, I do not overclock, have Win 7 x64 on an9300 quad core, Intel Extreme Motherboard, Nvidia GTX 275, 8Gig DDR 3 memory, andI am not able to complete a 3 hr cargo flight in 744X without this happening :(Funny thing is that I've flown a smattering of 747 flights in the past and don't believe this problem was happening, on both Vista and Win7, so right now I'm kinda perplexedwhat has changed that has made this SO unavoidable..... sigh...