分号-寻找错误的硬盘的方式
分号是从微软的Visual C网产品经理一个新的每月专栏 - 我们自己的尼克Hodapp。列拟直接线，以微软为你问这些问题，没有其他人可以回答。如果你曾经想知道内部的阴谋的VC编译器，或曾想以知道为什么一个特定的设计决定是的，或者想的内情，卷曲的Visual C问题已stumping你再在这里发表您的问题。每期将覆盖最好的或最有趣的问题。规则很简单:很有趣，使有关Visual C，永远不提的Visual Basic。
{S0}我有一些不幸的消息和一些高兴的消息。你肯定知道现在，微软发布的Visual C风口浪尖上。NET 2003的吗？？有很多伟大的新功能，包括ISO C的一致性和支持Windows窗体的10周年纪念版。这一不幸的消息是，我们最近发现了一个错误的产品，我们是无法修复之前释放。虽然这个错误并不影响每一个用户，甚至一半以上的用户，微软正在采取这种担忧严重，以解决C开发人员的需求。高兴的消息是，我们发现的bug，并提供一个永久性的解决方案是一个临时的解决方法修复，直到的。
弦oader锁的问题？？只影响使用混合模式的装配特征的C语言开发。它有可能导致在非常特殊的情况下的应用程序死锁。它不涉及到Visual C开发人员编写严格的MFC，ATL，甚至传统的Win32代码。它不涉及到C＃或Visual Basic开发人员，因为他们没有向他们提供这样的功能。
重要的是要注意的bug，而微软则重视这个问题，其实表面很经常和影响只有在非常特殊的情况下开发。我想告诉你，让你可以了解它是否会影响你和你的程序的bug。这个文本是不打算成为一个完整的技术故障问题。相反，这些话都是一个介绍。 。
如果你是一个C程序员使用Visual C。NET 2002或新的Visual C NET 2003中建立托管组件（集DLL）上运行。NET公共语言运行时（CLR），你的客户之一会影响人。这个bug严格的程序集包含两个原生x86和管理MSIL代码，并在既有的Visual C存在。NET版本2002年和2003年。目前，这不是一个可以由一个服务包处理错误。它的存在是由于建筑的错误。
外部微软很少有客户通知我们被臭虫咬伤。 （我们已经提供了这些客户的信息需要解决的bug。）这是不令人惊讶的bug表面相对较少。然而，在建立强大的应用程序利益，我们鼓励您熟悉自己所建议的解决方法程序和确定它是否应该被应用到你的代码。
国内几个微软的团队现在已经看到的bug清单，只有在涉及严重的系统压力，或在C混合模式已经过数字签名的程序集的测试情景。它把我们的团队三年来发现问题，并认识到其严重性和范围。
错误是不是一个安全级的错误。发生时，它会导致应用程序死锁。
今天的错误很少发生。这是严重的，因为它可能开始更频繁地发生变化是通用语言运行时（CLR），到Windows，或混合模式的组装技术更广泛采用。有些不可预知的错误发生。
如果你是一位经验丰富的Win32的开发人员，你可能会意识到你写的DllMain入口点函数的代码施加的限制。被称为Windows加载程序初始化DLL的DllMain。早已订明的DllMain代码不得调用KERNEL32 API的以外，不得启动线程，不得装载其他DLL等，但在混合模式的DLL有DllMain入口点定义，它很可能会招来一些行动CLR执行DllMain期间，这些非法的API。当发生这种情况的存在潜在的死锁发生。
混合模式的DLL链接到CRT或其他图书馆可能有一个"隐藏"的DllMain。
我们已采取步骤，以便在Visual C NET 2003编译器，以提醒开发人员，他们可能会受到这个问题。如果你试图编译一个混合模式的大会，定义一个DllMain，编译器/链接器将发出警告，称这是一个不安全的做法，大会应与使用"/ NOENTRY"开关。当然，如果大会链接到C运行时（一个很常见的场景），指定"/ NOENTRY"正在排放的第二个警告的影响。这一警告的圆形设计，并打算以指向文档的开发，关于这个问题，需要正确的步骤。警告消息本身包含链接到相应的文档。
解决方法步骤涉及到您的应用程序代码的变化。您将有编译/ NOENTRY您的程序集DLL项目，你将不得不运行您的DLL的DllMain函数比其他初始化代码。此错误的技术文档描述了需要采取的具体步骤。
虽然此修复程序相对简单，是因为它涉及到几个不同的技术，包括C编译器和CLR的建筑变化的原因，我们无法实施一个完整的修复在Visual C NET 2003。这在我们的产品周期后期这种变化会产生的涟漪，将有可能破坏释放的其他功能，并造成了重大的的延误。由于这个错误是本地化。NET开发人员，进一步C语言开发的一个子集的一个子集，我们已经决定继续航运的问题。在我们眼中，这些解决方法的步骤是不理想，但应该足以在紧要关头的情况下，我们英寸这里甚至是更好的消息:我们打算在接下来的主要版本的Visual C实现一个更开胃的修复，这将涉及不准从以往执行过程中的DllMain（编译器和CLR执行）的任何托管代码。此修复程序，一些额外的细节，将正确的问题完全。现在准备好您的的应用程序，该建议是从来没有建筑师或写在DllMain中明确托管代码。一个新锟standard？ - ？切入点，将发明专初始化托管代码和数据。
我锟m确保现在你们中许多人想知道什么设置任何其他的bug这个bug除了你锟v个人曾经在微软产品中遇到。为什么wouldn锟t微软只是静静地释放有关错误的文件，并让开发人员图自己的这一切呢？原因之一，这是真正的一个锟compiler错误？？一些开发商快速跳转到的结论是，在他们的应用程序的一个错误，其实是由于一个锟compiler错误？？有时，这原来是真实的，但大部分时间是ISN锟t。但它是真正的痛苦时，有一个编译器错误，特别是如果你锟rE的那些开发人员之一ISN锟t容易怀疑的工具集。加载程序锁的问题是一个编译器级的错误，我们不锟t想你失去任何睡眠。修复您的代码来变通解决的是什么，无可否认，我们的问题，然后继续前进。
其次，我认为这是一个很好的机会，提醒一下，往往忽略了有关的规则写在DllMain中的代码C语言开发。如果微软锟s自己的建筑师和开发商不经意地忽视这些规则，那么我锟l升敢打赌，你们中的一些有太多。
这说，我要你花15分钟到），和b）检查自己的应用程序锟s的DllMain（）函数。如果您发现有问题的代码，如果固定，纠正了在应用程序中的已知的错误，让我知道。使故事有趣的是，我锟l升送你一件T恤。
的功课第二件，而这一切的点，是一个）阅读和了解有关此错误的技术文档，B），确定它是否会影响你的代码C）修复它，如果它。
由于您锟v个人阅读这远，我锟绦想现在转，使代表继续和新的混合模式的装配功能的使用很短的呼吁。正如我锟v个人指出，在以前的1200字的功能也有一个bug，需要特别注意避免。渲染功能无用的呢？你应该避免创建本机/托管的组件，在C？这两个问题的答案是锟nØ？呢？
此功能的主要动力是使现有的基于C的应用完全托管的应用程序的整合，使现有的C库是从托管代码调用。其次它使您可以扩展现有的C代码的生命和功能，使托管库的无缝消费呢？？C语言开发，6年前开始在纯粹的Win32应用程序消耗COM和ActiveX组件的方式。有太多的宝贵的前忽视的。NET Framework中的类和接口。如果你锟r个人，为第三件（额外）的功课，我挑战你通过一个有趣的类的。NET Framework文档扫描，然后在C程序中消耗类。非常强大的技术，是吗？
我希望你赢锟t写使用此功能关闭，只是因为它有一个污点。
分号是在3个月的沉寂这个冬天，我不希望它消失了这么久再次。我锟绦爱有更积极的东西，谈下一次，所以如果你有任何燃烧的问题，你锟绦像我写的一切手段，向他们发送我的方式。
