|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Hang when new DirectoryEntry declaredI have noticed some very strange behaviour related to the DirectoryEntry class. If I debug the following code with a break point on the Console.WriteLine line then there is a lengthy pause before the breakpoint is hit. If I remove the DirectoryEntry line then the breakpoint is hit immediately. static void Main(string[] args) { Console.WriteLine("Test"); DirectoryEntry dirEntry = new DirectoryEntry(); } Also this only happens when I am debugging in Visual Studio. If I run the console app on its own there is no pause. The only thing I could come up with initially was that maybe there was a static constructor that was firing, but this didn't really seem to make sense and looking at the source for the DirectoryEntry class I can't see anything that would account for this pause. Any ideas would be appreciated. Regards Ian Hi Lan,
This looks like a very strange issue, since the DirectoryEntry dirEntry = new DirectoryEntry() line is not executed yet. I performed a lot of search in all available public and internal database and resource, but can not find similar report. So I suspect this issue may be your machine specific or project specific. Can you please help to perform the following tests? 1. Move your problematic VS.net2003 project on other machine, does this problem occur either? 2. Create a new console project with these code snippet does this problem exist? 3. You use another debugger to debug your application, then we can determine if this problem is VS.net2003 debugger specific. For example, you may use windbg with SOS.dll to debug your assembly, does the lengthy pause still exist? 4. If you remove the breakpoint on the Console.WriteLine and run your project under debugger, will the "Test" appear in console output immediately or also experience the lengthy delay? This test will help us to identify whether the problem is related with the breakpoint. I look forward to your feedback. Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. Thanks for the response Jeffrey.
> 1. Move your problematic VS.net2003 project on other machine, does this It seems to be specific to my machine.> problem occur either? > 2. Create a new console project with these code snippet does this problem Yes it does. It also does the same if I use a web project.> exist? > 3. You use another debugger to debug your application, then we can If I use windbg to debug then it seems to behave normally> determine if this problem is VS.net2003 debugger specific. For example, > you > may use windbg with SOS.dll to debug your assembly, does the lengthy pause > still exist? > 4. If you remove the breakpoint on the Console.WriteLine and run your If I removed the breakpoint it still has the delay before "Test" appears on > project under debugger, will the "Test" appear in console output > immediately or also experience the lengthy delay? This test will help us > to > identify whether the problem is related with the breakpoint. the console, so I don't think it is related to the breakpoint itself. Also if I move the DirectoryEntry call into another class it doesn't hang untill I try and create an instance of that class. As soon as the execution gets to the creation of the new class it hangs, and the debugger takes several minutes before it gets to the constructor. Regards Ian Hi Lan,
Thanks for the information! Oh, is it possible your machine has setup the symbol server for the VS.net2003 debugger? If this is true, the VS.net2003 debugger is trying to load the symbol for the loaded modules now, so that the UI response is slow. VS.net2003 debugger uses early symbol loading that is if you set the Microsoft symbol server for the VS.net2003, the VS.net2003 will load all the symbols for all the modules in the application after you pressed F5. Loading symbols for all the modules is a lengthy operation which requires some time. Since Windbg uses delay symbol loading, it will not experience this delay. Also, since DirectoryEntry class resides in System.DirectoryServices.dll assembly, so its symbol will reside in a separate file, which may require some addition time to download from Microsoft symbol server. If you do not use DirectoryEntry class in the application, your application will not load System.DirectoryServices.dll assembly, so the VS.net2003 debugger will not download the symbol file for System.DirectoryServices.dll. This may explain why removing the DirectoryEntry class code will eliminate the delay. To check if you are experiencing the VS.net2003 debugger symbol loading delay, I recommend you click View->Other Windows->Output menu item to open the Output window in the VS.net2003 IDE after you pressed F5. Then you can check if there are additional symbol loading statements like below: 'DefaultDomain': Loaded 'c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll', Symbols loaded. 'ImmediateWindowTest': Loaded 'G:\Program\winform\2006\9-20\ImmediateWindowTest\bin\Debug\ImmediateWindowT est.exe', Symbols loaded. 'ImmediateWindowTest.exe': Loaded 'c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\s ystem.windows.forms.dll', Symbols loaded. 'ImmediateWindowTest.exe': Loaded 'c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll', Symbols loaded. 'ImmediateWindowTest.exe': Loaded 'c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\system. drawing.dll', Symbols loaded. 'ImmediateWindowTest.exe': Loaded 'c:\windows\assembly\gac\system.data\1.0.5000.0__b77a5c561934e089\system.dat a.dll', Symbols loaded. 'ImmediateWindowTest.exe': Loaded 'c:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml. dll', Symbols loaded. The "Symbols loaded" in the output means that you have set the symbol server for the .Net FCL assemblies. You may also check "_NT_SYMBOL_PATH" environment variable in your system. This is the environment variable VS.net2003 debugger uses to set symbol servers. I will wait for your further confirmation regarding this guess. Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. That sounds like a good possibility.
This is what I see in the output window: 'DefaultDomain': Loaded 'c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll', No symbols loaded. 'ADTestConsole': Loaded 'C:\ADTest\ADTest\ADTestConsole\bin\Debug\ADTestConsole.exe', Symbols loaded. 'ADTestConsole.exe': Loaded 'c:\windows\assembly\gac\system.directoryservices\1.0.5000.0__b03f5f7f11d50a3a\system.directoryservices.dll', No symbols loaded. 'ADTestConsole.exe': Loaded 'c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll', No symbols loaded. Although it does say no Symbols loaded I am still wondering if your hunch is right, because it doesn't output the "...System.DirectoryServices.dll No Symbols Loaded" line until after the large pause. My _NT_SYMBOL_PATH env variable is set to "SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols". I think I set it to this when I was trying to debug an issue with IIS. .... I have just tried setting it to c:\windows\symbols and I now don't get the pause. So I think you were right. Thanks for the help! Regards Ian ""Jeffrey Tan[MSFT]"" <je***@online.microsoft.com> wrote in message Show quote news:ugS7buS3GHA.400@TK2MSFTNGXA01.phx.gbl... > Hi Lan, > > Thanks for the information! > > Oh, is it possible your machine has setup the symbol server for the > VS.net2003 debugger? If this is true, the VS.net2003 debugger is trying to > load the symbol for the loaded modules now, so that the UI response is > slow. VS.net2003 debugger uses early symbol loading that is if you set the > Microsoft symbol server for the VS.net2003, the VS.net2003 will load all > the symbols for all the modules in the application after you pressed F5. > Loading symbols for all the modules is a lengthy operation which requires > some time. Since Windbg uses delay symbol loading, it will not experience > this delay. > > Also, since DirectoryEntry class resides in System.DirectoryServices.dll > assembly, so its symbol will reside in a separate file, which may require > some addition time to download from Microsoft symbol server. If you do not > use DirectoryEntry class in the application, your application will not > load > System.DirectoryServices.dll assembly, so the VS.net2003 debugger will not > download the symbol file for System.DirectoryServices.dll. This may > explain > why removing the DirectoryEntry class code will eliminate the delay. > > To check if you are experiencing the VS.net2003 debugger symbol loading > delay, I recommend you click View->Other Windows->Output menu item to open > the Output window in the VS.net2003 IDE after you pressed F5. Then you can > check if there are additional symbol loading statements like below: > > 'DefaultDomain': Loaded > 'c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll', Symbols > loaded. > 'ImmediateWindowTest': Loaded > 'G:\Program\winform\2006\9-20\ImmediateWindowTest\bin\Debug\ImmediateWindowT > est.exe', Symbols loaded. > 'ImmediateWindowTest.exe': Loaded > 'c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\s > ystem.windows.forms.dll', Symbols loaded. > 'ImmediateWindowTest.exe': Loaded > 'c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll', > Symbols loaded. > 'ImmediateWindowTest.exe': Loaded > 'c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\system. > drawing.dll', Symbols loaded. > 'ImmediateWindowTest.exe': Loaded > 'c:\windows\assembly\gac\system.data\1.0.5000.0__b77a5c561934e089\system.dat > a.dll', Symbols loaded. > 'ImmediateWindowTest.exe': Loaded > 'c:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml. > dll', Symbols loaded. > > The "Symbols loaded" in the output means that you have set the symbol > server for the .Net FCL assemblies. > > You may also check "_NT_SYMBOL_PATH" environment variable in your system. > This is the environment variable VS.net2003 debugger uses to set symbol > servers. > > I will wait for your further confirmation regarding this guess. Thanks. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > Get notification to my posts through email? Please refer to > http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif > ications. > > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues > where an initial response from the community or a Microsoft Support > Engineer within 1 business day is acceptable. Please note that each follow > up response may take approximately 2 business days as the support > professional working with you may need further investigation to reach the > most efficient resolution. The offering is not appropriate for situations > that require urgent, real-time or phone-based interactions or complex > project analysis and dump analysis issues. Issues of this nature are best > handled working with a dedicated Microsoft Support Engineer by contacting > Microsoft Customer Support Services (CSS) at > http://msdn.microsoft.com/subscriptions/support/default.aspx. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no > rights. > Cool, that is it!
If you do not want to debug .Net BCL assemblies, it is a good idea to not provide _NT_SYMBOL_PATH for the system, then the VS.net2003 debugger will not try to load symbols for .Net BCL assemblies, which will improve a lot of performance during debugging :-) If you need further help, please feel free to post. Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.  |
|||||||||||||||||||||||
Other interesting topics