Conflict between ICQ and Delay() :-/

va!n · Post by **va!n** » Wed Apr 20, 2005 12:59 pm

hi!
i have found an very very unserious problem and i have no idea what went wrong in my system! i use windows2000pro with all fixed and latest SP and DX9 (feb 2005 release)!

Code: Select all

OpenConsole()

For test = 0 To 10

Repeat
  Delay(1)
  loop = loop+1
; Debug loop
Until loop = 1000  : loop = 0

PrintN("#")

Next
End

Topic source should count loop up to 1000 and wait so all in one 1000ms = 1 second, right? therotecial...

This works fine when i have run ICQ2003Pro in the background! But the curious thing is, when i turn off ICQ, the same code runs very very slow (without debugger and same on exe!)!

Its sooo slow, that i have only to wait up to 80ms (for computer this are only 80ms but in real this are up to 1000ms! Very strange!) I checked taskman and its all fine with CPU usage and memory)!

btw, i own an AMD3200+ WInchester (supports 64bit)! When i run ICQ again, and try to compile, it works again fine (normal speed)

soneone an idea what happen here??? (i would understand it, if the problem only exist if icq would run... but the curious thing is, that it still only happen, if ICQ dont run....

EDIT:
i have tried to replace Delay() by Sleep() = no different! And there are no add nor unknown tasks running in background! (checked!)

va!n · Post by **va!n** » Wed Apr 20, 2005 1:05 pm

Ok, i have checked my full system with NOD32 (antivirus) using the database from today (20-april-2005) and have found no virus or something!

Next step i have tried to create an exe while running ICQ in background and once without running ICQ in background!

Both versions have the same size BUT there seems to be something different! I did a CRC check on both files! (both versions used exactly the same source!)

Here are the results:

Exe_WithRunningICQ = 4.608 byte | CRC: 7B8D8878
Exe_WithoutRunningICQ = 4.608 byte | CRC: AA982DFA

whats going on here?

blueznl · Post by **blueznl** » Wed Apr 20, 2005 2:07 pm

did you try to generate TWO exe's both without icq? did those have identical crc's?

PB · Post by PB » Wed Apr 20, 2005 2:12 pm

> did you try to generate TWO exe's both without icq? did those have
> identical crc's?

They won't anyway, as the compile time/date stamp will be different.

va!n · Post by **va!n** » Wed Apr 20, 2005 2:40 pm

blueznl wrote:did you try to generate TWO exe's both without icq? did those have identical crc's?

i tried to compile the same source two times! one time with running ICQ in background and once without running ICQ in background! Both versions have not the same CRC, possible of its timestamp as PB said! I didnt thought about that point!

However, both exe versions running fine when ICQ is not running, else the Delay() alias Sleep_() command is very very slow... (but all the other running tasks are working very fine - no slow down)

its really magic...

Post by **Fred** » Wed Apr 20, 2005 5:38 pm

Delay() is just a wrapper for Sleep_() so it should have a conflict between ICQ and Windows.

Ralf · Post by **Ralf** » Wed Apr 20, 2005 11:08 pm

Fred wrote:Delay() is just a wrapper for Sleep_() so it should have a conflict between ICQ and Windows.

yes, i know and you are right! the only crazy thing is, the problem only appears if ICQ is NOT running! When running ICQ, the problem is gone! (i dont know where and how to start, to fix the problem - i will try to fix it! anyway many thanks!

Rescator · Post by **Rescator** » Thu Apr 21, 2005 12:35 am

replace the PrintN()
with a Debug and run in debug mode.
it could be the console default output pipe (stdout)
that is interfered with somehow.

If you had said it was slower WHILE icq is running I'd have said "aha".
but since it's the other way around. (and you are sure you "quit" icq and not just hid it/stuck it in the tray?)
This sounds very odd indeed.
Do the check I said. if no change, comment out OpenConsole and run debug again. I suspect that your console output is messed up somehow,
not sure how, but as it changes as you start/quit icq I'd still point my finger at icq as the sinner.

Delay(1) on it's own is not guaranteed to always be 1ms,
it is guaranteed (or should be) to delay/sleep for "at least" 1ms + whatever overheads there are.
(i.e. calling a function/procedure/api call, or in this case the loop has the overhead of the PrintN so if that is very slow the loop gets slow).

Also note that small values less than Delay(20) (20ms) may be innacurate,
I think someone mentioned that normal (non high-resolution) timers can not do very low ms timing,
and as far as I know, Delay() is a low resolution wait/sleep timer.

va!n · Post by **va!n** » Thu Apr 21, 2005 12:44 pm

i tried all, like replace printn() by debug, just use only the loop without any console stuff and so on = still the same problem!!!

it only slows down if ICQ is NOT running (not on tray nor in any ICQ part in the system processes!)

I have tried to reinstall the ICQ version to solve the problem - no luck! still the same thing!

yes i know that delay() isnt a high resolution timer, but it cant be right, that 80 ms takes around 1000 ms! (less as 80 would be ok but not more)

in the meantime i think, due fact ICQ is reading/writing all the time to the registry (even if you only run it in background and dont use it), that ICQ trashed something in the system and if you run it, it will change it for its use), when exit it, it will set it back to the old stuff!?

I will continue to solve this curious part else i will reinstall the system ;/ thanks for all answers

GedB · Post by **GedB** » Thu Apr 21, 2005 1:55 pm

The win32 docs give this warning regarding sleep_()

You have to be careful when using Sleep and DDE. If a thread creates any windows, it must process messages. DDE sends messages to all windows in the system. If you have a thread that uses a wait function with no time-out interval, the system will deadlock. Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than Sleep.

Perhaps ICQ is creating a problematic thread which it then fails to close. While ICQ is alive it manages the thread OK. However, once ICQ is closed the thread is left dangling, waiting indefinately.

Grab an appropriate system tool that lists threads and processes and take a look.

Process explorer might be useful
http://www.sysinternals.com/ntw2k/freew ... cexp.shtml

Dunno really, just guesing.

GeoTrail · Post by **GeoTrail** » Thu Apr 21, 2005 2:03 pm

You could try to disable ICQ from starting with Windows, and restart the computer and then try the program again and see if that makes any difference.

va!n · Post by **va!n** » Thu Apr 21, 2005 2:28 pm

@GedB: thanks for the info about the win32 docs! i use the procesxp tool since months

thanks

@GeoTrail:
i dont have any program in autostart nor in registry RUNS - so no program will be start when booting my system - only DLL drivers of course! thanks

tinman · Post by **tinman** » Thu Apr 21, 2005 11:21 pm

If I run this with the debugger on (no ICQ) I get around 8 seconds between the hashes getting printed. I guess this is the problem you have?

If I disable the debugger it is between 1-2 seconds, which is what I would expect because the scheduler time slice on Windows (non server versions) is usually 15ms, which means that for every Delay(1) you will be stopped running for probably 15ms, depends on what other tasks are running.

When the console window is inactive then it seems to take longer again.

GreenGiant · Post by **GreenGiant** » Fri Apr 22, 2005 4:08 pm

If for every delay(1) you stopped for 15ms, you would expect the code to stop for about 15secs. Try this

Code: Select all



OpenConsole()

Delay(20000)

PrintN("#")

For test = 0 To 10

Repeat
  Delay(1)
  loop = loop+1
; Debug loop
Until loop = 1000  : loop = 0

PrintN("#")

Next
End

I've noticed PB programs running slowly to begin with.

tinman · Post by **tinman** » Mon Apr 25, 2005 9:50 am

GreenGiant wrote:If for every delay(1) you stopped for 15ms, you would expect the code to stop for about 15secs. Try this

Yeah, sorry I was being a chump and not multiplying correctly. However, if you have another task running which is active or a whole bunch of tasks, then the accuracy of your delay will be closer to the cheduler time slice than what you want from Delay().