Hang when new DirectoryEntry declared

  • Thread starter Thread starter Ian Cox
  • Start date Start date
I

Ian Cox

I am using the System.DirectoryServices namespace in .net 2003.
I 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
problem occur either?
Click to expand...
It seems to be specific to my machine.
2. Create a new console project with these code snippet does this problem
exist?
Click to expand...
Yes it does. It also does the same if I use a web project.
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?
Click to expand...
If I use windbg to debug then it seems to behave normally
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.
Click to expand...
If I removed the breakpoint it still has the delay before "Test" appears on
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]" said:
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.
Click to expand...
 
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.
 
Back
Top