.Net application almost stalls the system

[alag20]

Hi,
I am making a c# application which seems to be stalling the system. When I check the system properties in task manager, it shows that I am hardly using any memory or cpu. Still when I run this app, then the whole computer slows down termendouly and I am not able to do anything else.

Can someone please advise why something like this might be occuring?

[DrBunchman]

What happens when you run the app on your development machine in debug - do you have the same problem?

Dr B

[jamesd0142]

Sounds to me like you have a some sort of never ending loop/process running

[DrBunchman]

Sounds to me like you have a some sort of never ending loop/process running

That's what I was thinking too.

[alag20]

That's what I was thinking too.

Well the application does finish and exits in approx 5 - 6 mins so the application is working through the process, but its other applications which seems to be hanging or playing as if dead and no system resources availlable when the cpu is 98% idle and more than 2/3 memory [as I have 2 gb ram] is availble for use!

[DrBunchman]

What's the app actually doing?

[alag20]

What's the app actually doing?

Well it patches a binary file. But this file is not being used anywhere or in anyway!

[Plater]

Do you use any COM objects or do any DLL calls?
Or is it all .NET functions?

If you have a loop that process a large binary file, even though the CPU/memory are fine, you are probably bogging down the harddrive. That is not easy to track with taskmanager. If the binary file is large, chances are it's fragmented, and if you frequently download/copy/delete large files, your drive is probably fragmented heavily. That increases seek times. It can be devastating on 5400rpm drive.

If you want this program to be "running in the background" you should consider slowing down its I/O access in some manor so that other harddrive calls (like paging system) can be made.

[alag20]

Do you use any COM objects or do any DLL calls?
Or is it all .NET functions?

If you have a loop that process a large binary file, even though the CPU/memory are fine, you are probably bogging down the harddrive. That is not easy to track with taskmanager. If the binary file is large, chances are it's fragmented, and if you frequently download/copy/delete large files, your drive is probably fragmented heavily. That increases seek times. It can be devastating on 5400rpm drive.

If you want this program to be "running in the background" you should consider slowing down its I/O access in some manor so that other harddrive calls (like paging system) can be made.

Hi Plater,
Thanks for your help. How can I slow down I/O access from .Net. The uncompression is written in 32bit C application which i call from .Net!

[Plater]

I thought so.
Does it do it "all at once" like you make the call and it does it's thing. Or do you loop through with helper calls? If there's a little of involvement on your side you can just put in thread sleeps to slow it down and give other threads priority, but the win32 might like "lock" the device(harddriv e) somewhat, unsure.

Is it just an "unzip" type decompression? .NET can do the simple decompression stuff.

[alag20]

Hi Plater,
Thanks for your help. How can I slow down I/O access from .Net. The uncompression is written in 32bit C application which i call from .Net!

Also it seems to be better in Debug / Release mode from VS2005

[alag20]

I thought so.
Does it do it "all at once" like you make the call and it does it's thing. Or do you loop through with helper calls? If there's a little of involvement on your side you can just put in thread sleeps to slow it down and give other threads priority, but the win32 might like "lock" the device(harddriv e) somewhat, unsure.

Is it just an "unzip" type decompression? .NET can do the simple decompression stuff.

It is binary difference file uncompression and .Net cant do it on its own without various algorithms etc. I just call the it as Process.Start() with params. Then I wait in .Net to check if the thread has completed. Here [on .Net side] I have a thread.sleep for .net thread to go and check the application every few seconds to see if it has completed.

[Plater]

So you already had a thread sleep and it was still locking up the system?

[alag20]

So you already had a thread sleep and it was still locking up the system?

Yes it still seems to hog when I execute it. It is alot better if I run it from Visual Studio [pointing to the directory and then debugging under debug / release mode]

[Plater]

Very weird.
Is the code that executes the sleep (as well as other stuff) run on the same thread as the gui?
That's really all I can think of for debug making it better, the threads are run a little differently in debug mode.