跪求WPF内存不足，无法执行该程序的解决方案，急急急！！！！！！！！

Question

跪求WPF内存不足，无法执行该程序的解决方案，急急急！！！！！！！！
我们用WPF做了一个自动售票机的应用程序，当运行这个程序的时候，只要该程序用到了200M的时候就会报内存不足，无法执行该程序这个异常，希望有NB的大哥帮忙看看是怎么回事，有没有解决的方法。这个机器的内存应该足够可以使用，内存是1G的，内存最高使用到800M左右；
我们用到了GC、用到了[DllImport("kernel32.dll")]
        public static extern int SetProcessWorkingSetSize(IntPtr proc, int min, int max);
方法进行清理，程序进程的内存是减少了，但是虚拟内存还是没有减少；
跪求解决方案啊，。

Answer 1

内存太小了 .netframework GC 会保护内存溢出

Answer 2

内存应该不小吧，内存是1G的，加上物理内存，可使用的内存也在2个G，该系统加上windows使用的，最高在800M。

Answer 3

WPF本身就有BUG。而且很多。
放弃WPF吧。SetProcessWorkingSetSize这个函数并不是降底内存使用率。而是让你的程序跑的更慢。具体的查MSDN。
如果你大量使用图片。先把所有的暂时隐掉再看看。
如果问题解决了，再把最常用的那个图片做一下缓冲。
因为你的程序不大。当你的程序很大时WPF会有更多问题。

Answer 4

是图片没有释放造成的，另外我发现zanfeng是不是有病，到处说WPF的坏话，自己不喜欢没必要诋毁它，别人是在问问题，而不是宣传WPF。WPF本身对内存的占用是比较高，特别是特效开多的话。但它的确是各非常好的界面开发工具，对于设计自定义控件非常适合。由于图片资源是非托管的，因此对于图片的释放很重要，你可以做个按钮，随时点击下，输出托管内存大小,通过GC.GetTotalMemory可得到托管内存大小，当再次提示内存不足的时候，你再看看托管堆的大小，如果托管堆并不大，说明是非托管资源的内存泄漏，如图片。

Answer 5

哈哈。WPF确实是垃圾啊。
没病只是不想有人在这上面浪费时间。最终做东西又要重头来。关于WPF的BUG也不是我讲的。 

Answer 6

有错误信息？你如何确定是内存不足？还是没有错你想优化内存一点？
WPF你用storeboard做了一些动画，是比较耗内存，还是WPF 的Effect,内外发光是很占CPU和内存的，建议不要用。zanfeng， 这个人就完全不懂WPF的，在说WPF不好。

Answer 7

如果是想用现成控件，如果是不想使用绑定的，自然不会去用WPF，WPF的BUG都来自微软自带的控件，微软没有给出非常好的自带控件不代表WPF语音本身不好，你完全可以自定义控件，也可以在微软提供的原始控件基础上修改，灵活性比WinForm大得多，还提供了各种手段避开所谓的BUG，但这些在WinForm里面是无法实现的，就是因为WPF的强大才做得到。至于一些不如人意的地方，微软也会不断改进，也有第三方控件提供支持，所以我们应该看到它的优势，而不能因为不成熟就诋毁它，我是非常看好WPF的。
补充一点：如果是因为某些WPF控件的使用有BUG，完全可以用WinForm控件替换，它和WinForm的互操性没任何问题，但框架使用WPF的话，就有其灵活性的优势。

Answer 8

WPF 却实有bug，而且还很多

Answer 9

因为这是怎个程序的问题，没办法发代码啊你们在做WPF的时候有没有出现过内存不足，无法执行该程序的异常。有的话是怎么解决的。

Answer 10

你可以在程序运行中监视内存变化，分析是什么动作引起的，逐步缩小范围排查。
另外没遇到过内存不足导致程序无法执行的，代码中各处内存释放都做得很好，即使只有512内存也跑得欢，另外少用GC释放，禁用SetProcessWorkingSetSize，那两个副作用大于好处，具体原理就不细说了。

Answer 11

使用WPF的时候，只见内存增加，但不见减少。不知道是什么原因。主要是系统的东西没有得到释放

Answer 12

这是因为你的图片资源没有被释放，必须显式调用你使用过的Image类型对象的Dispose方法，否则图片资源是不会被GC自动回收掉的，因为这一部分资源是非托管的。

Answer 13

WPF 有这个毛病，我记得同事提过他以前遇到过这个问题，导致整个项目作废了。

Answer 14

楼主这个应该不会是wpf的bug。你不提供代码没有人能帮到你的。

Answer 15

我们用WPF做一个银行的大项目呢。没啥大问题。挺好。