cool！！！

帅哥楼主失踪了？建议给100楼内的每人发几个t恤穿穿

mMVP - Mini MVP
或者直接叫plus算了，就不用gdi了。

楼主，不建议你把破解的东西放在这里，会有版权纠纷的。

第一个题目，看到这么多讨论，突然感觉很像侠客行里面，各位大虾研究诗句的那一幕。

貌似，4年前学过一个月
据说，这四个东西，ms正在用C#重写。

I/O已经降低了20倍，你该知足了，哈哈！

你这么想，原来100个人同时call这个sp，I/O是17万，而现在仅仅是0.76万！时间不能说明什么，尤其是单个进程来测试，没有意义。你关心的重点是I/O的降低，I/O低了，大并发下，时间自然会降低，block自然会大大减少。

直接用devent myproj.sln /rebuild release，08也好使，如果加参数/u，编译好后，可以直接运行

具体的在.net command prompt下面执行：devenv /?

现在是5个评论了...除了你自己的,哈哈!

base在上海，有意向的，请和偶联系：juqiang@live.com。欢迎各位有识之士！

There's two problems here:

1. There's some sort of interop problem you're hitting where the .Net
wrapper code that it's generating isn't coming out right for some reason;
maybe the typelibrary info in rule.dll is broken, maybe it's just .net
being unhappy. There's no good way around this other than doing the
IDispatch calls by hand.

2. rule.dll wraps Extended MAPI, and Extended MAPI and .Net don't mix
nicely, so even if you did get it to work, you could hit threading
problems, general runtime pain, etc:

http://support.microsoft.com/kb/813349

Solution: don't use a .Net language, use classic Visual
Basic/C++/Delphi/whatever.

lbq，我加入你msn了，请给我回复一下，3x。

vs2002可以这么用，现在赞同楼上的，用msbuild好了！

另外，楼主应该把vss的加进去，十几个人的小项目还是很方便的。如ss get什么的。

cool!!!

yes，蛙蛙，!finddebugmodules、!finddebugtreu、!aspxpages、!dumpaspnetcache等，都是1.x的，我用了公司内部的psscor2来dump的，你可以到toolbox上下载一个。

to 暗香，多做几次就熟悉了，你可以看tess得早期文章：http://blogs.msdn.com/tess，从最早的开始看。

你还是等负载上去了再抓一个dump吧，如果用debugdiag，那么不要用memory leak的option，直接在内存在700-800M左右的时候抓即可。

保险点的，这个建议你这么做，观察，到内存在700M左右的时候，在debugging tools for windows目录下面执行：

adplus -hang -pn w3wp.exe -o c:\dumps -quiet

等抓dump窗口消失后，你再跑一下下面命令：
adplus -crash -pn w3wp.exe -o c:\dumps -quiet
这个命令是看w3wp是否会因为OOM而crash掉。

结论貌似错误的，55555.。。。兄弟我mail你了，OracleDataReader你没有关闭，你查找一下所有的代码看看。

结合文中最开始的debugdiag中的callstack：processrequest/timercallback/hashtable，偶认为基本能验证我下面分析的问题，cache没有退出的机制（或者时间N长，来不及退出，就已经因为Cache太大，而 OOM了）

2楼的，如果是递归引起的OOM问题，你抓一个adplus -pn name.exe -crash -o c:\dumps即可，name.exe一般是w3wp.exe/aspnet_wp.exe或者你自己的winform.exe等

然后windbg打开后，会自动切换到exception的地方，然后你kb 200或者!clrstack，就能看到N多代码重复执行。递归造成的crash，偶认为相对很容易解决的问题，包括100% cpu。

越发感觉到如果不熟悉CLR，不熟悉object的struct，这个鸟东西很难看。。。用reflector能帮助你猜点东西而已。。。

昨天看那个帖子看了半天，很郁闷，我和业余程序员的指标非常接近。专业的，基本不靠谱。

偶到现在还凭兴趣做事，本以为工作这么多年了，该专业点了，谁知道，还是个非专业人士，郁闷啊！！！

顶一下怪怪！！！

牛贴！到2008年了，哈哈！！！

楼上的，一直看你的blog，呵呵。tess的东西非常好，你坚持下去吧！！！我从里面学习到了不少东西。

一个速查手册而已，如果能记住，就不用看了。

cool!!!

还有一个逼近，不过有点取巧了，因为乘方也够难算的了。

(128/125)^30=2.0370>2，那么取lg后得到：
30*lg(2^7/5^3)>lg2，展开后得到：
30*(7lg2-3(1-lg2))>lg2，继续：

210lg2-90+90lg2>lg2，最后得到：

lg2<90/299=0.3010，这个四位是很准确的了。

MVP原来是这个意思，#汗……

64<<10，左移10位，就是64×1024

.load clr20\sos.dll，你要先执行的。sos.dll在默认的c:\windows\microsoft.net\framework\v2.....下面，你复制到c:\program files\debugging tools for windows下面的clr20目录下面（clr20是你手工创建的）

刚刚起个头，有空继续写。

投了dudu一个，怎么那天看，只有一票？

老大已经两年没有出手了。。。期待ing。。。

偶的经验是，性能与架构、设计基本无关的，与细节有关。细节要求你对os/db/debug/coding，都要熟悉，越熟悉越好。

比如说，索引那些东西，就要考虑索引的实现机制。网络上总结的那么一坨又一坨的sql编写事项、索引注意事项等，实际上只是表面的东西。理解了原理，你就什么都清楚了，不要背那么多教条了。

very cool, mark!!!

cool!!!严重支持！！！

to yok，我没在1.1下面看过，如果没有，我估计是sos当时没有加这个东西而已。

to zealic，我担心的就是等exchange的补丁，那我就死定了。。。希望偶老大能帮我找到真正原因，并且有一个婉转的解决办法。。。

兄弟，送两件t-shirt或者衬衣给偶吧，没衣服穿了，55555.。。。。。

jeffrey，我明天后天都在公司，你去找我吧！其他时间，我在外面做项目，很难回去的。

delphi的string，有一个E文的文章仔细分析过，不过忘记了。

晕，3年前的帖子，居然也被翻出来了。

up

lixiong就是葡萄

他啥都搞过……

mark

mark

书叫做：Windows用户态程序高效排错

作者熊力，nick name是eparg，倒过来是葡萄，so，偶就这么称呼他了。

楼主济南的？老乡啊，哈哈！

up !!!

5楼的，“The following requested processes are not executing”这句表明，你要的进程没有执行，当然抓不到了。我工程名字叫做SOSBasics，所以，编译后的文件默认也叫做SOSBasics.exe。

你工程名字加入叫做demo，那么编译后的叫做demo.exe，那么你的脚本应该是：
adplus -hang -pn demo.exe -o c:\dumps

前段时间去过华硕，汗一下哪里严格的保安措施。。。
有机会到苏州找你吃螃蟹去，请不要客气，哈！

汗一个，偶还不知道，谢谢justin

更正一下，上面的小结
2、整个gc heap的size是：494000，大概50k左右。
3、看我们抓到的那个dump文件，大小是55,252,827字节，55K左右。说明大部分都是托管资源占用的内存。

应该是：
2、整个gc heap的size是：494000，大概500k左右。
3、看我们抓到的那个dump文件，大小是55,252,827字节，55M左右。说明大部分都是非托管资源占用的内存。