Strange behavior during appdomain unloading

[Ice]

Folks -

I am observing some weird behavior in our application during shutdown, let
me see if I can explain this clearly.

Lets say I open 2 instances - A and B - of the application on my machine.
Regardless of what order I shutdown the instances, the process associated
with A always takes longer to end than the process associated with B. Also
there is a noticeable 100% CPU spike during the shutdown of instance A which
I never see with instance B.

To make this even more interesting, if I never shutdown instance A, then all
subsequent instances started shutdown and exit their processes in a timely
fashion even if instance B is shutdown. However, if I shutdown instance A,
the first (and only the first) instance started after this shutdown exhibits
the same behavior as instance A.

Has anyone seen this kind of behavior before? Does the framework do
something different the very first time the application is started like
security checks etc? that it wouldn't do for subsequent startups/shutdowns?

Any ideas would be greatly appreciated.

Thanks.

Ice

[Ashok Kamath [MSFT]]

I have some questions to try and figure this out. First to confirm, this is
an issue at process shutdown, and not at appdomain unload, correct?

Is this behavior seen in any managed app on that machine, or just one
particular app? If it is one particular app, could you briefly describe the
app?

What is the OS on the machine where you saw this? Do you have admin
privileges on the machine? Is the behavior seen on multiple machines?

Thanks
Ashok

[Ice]

The behavior is definitely seen when I "exit" the application.

I have noticed this behavior in only one managed app. Its n-tier application
that uses .NET SCs running remotely. Let me know if you need more inform.

I've seen the behavior on both 2000 and 2003 OSs. I have admin privileges.

ice
"Ashok Kamath [MSFT]" <ash...@online.microsoft.com> wrote in message
news:1%23g9dVsC...@cpmsftngxa06.phx.gbl...

[Ashok Kamath [MSFT]]

Ice, the best way to narrow this down is to use a managed code profiler as
this seems specific to one application. I suspect that finalization of
certain objects could be the issue.
If you dont have access to a managed code profiler, and if the CPU spike
lasts long enough, you could do "manual" profiling by breaking into the
debugger a few times and seeing the callstack. I am sure you can find the
symbols for mscorwks.dll in the .net sdk. This blog might be useful too -
http://blogs.msdn.com/mvstanton/
Contact me offline is you need more information.

Ashok

[Ice]

I actually think this is due to the maintenance of the app .ini file. When
there are a lot of assemblies used by the application, there is significant
overhead writing to the file.

ice
"Ashok Kamath [MSFT]" <ash...@online.microsoft.com> wrote in message

news:SJw7F9kI...@cpmsftngxa06.phx.gbl...

[Conrad Zhang]

Ice,

This is by-design.

Fusion keeps application's assembly binding history in a ini file, which you
can find in %userprofile%\Local Settings\Application
Data\ApplicationHistory. The ini files are fed to .Net Application Restore
tool, which you can find here
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/ht
ml/cpconusingnetapplicationrestoretool.asp). At the application shutdown
time, fusion will flush the application's assembly binding history to disk.
If there are many assemblies, it may cause the CPU spike you observed.

The interesting behavior you see, is because fusion open a lock file for
each application instance. The first instance will grab the lock. All the
other instances will fail to grab the lock since it is already held by the
first instance. Fusion will record and flush assembly binding history only
if the lock is held (to avoid corruption on the ini file). That is why you
did not see the CPU spike on instance B. Only the one with the lock held
will see the CPU spike.

Clear as mud? Or Hawaii sky?

Thanks,

"Ice" <i...@nospam.com> wrote in message
news:Ovl0SVdB...@TK2MSFTNGP09.phx.gbl...

[Ice]

Sure, I discovered this the hard way :) It says a to having a lot of
assemblies in your application.

ice
"Conrad Zhang" <conrad_zhang AT yahoo DOT com> wrote in message
news:%236evKT%23IEH...@tk2msftngp13.phx.gbl...

[Conrad Zhang]

The binding history logging is turned off in Whidbey. The Fusion binding
logic becomes too complicated for App Restore Tool to handle. We will pursue
a different approach in the future to give the same functionality.

As a result of this change, App Restore Tool will be removed from redist.

"Ice" <i...@nospam.com> wrote in message

news:u%23vHTZ%23IEH...@TK2MSFTNGP09.phx.gbl...