Opened 12 years ago

Closed 12 years ago

Last modified 10 years ago

#73 closed Bug (fixed)

Very slow (and system-blocking) start of CT2 in Release

Reported by: Arno Wacker Owned by: Matthäus Wander
Priority: Must have Milestone:
Component: CrypWin Keywords:
Cc:

Description

When starting the installed CrypTool 2.0 version (release), the startup procedure hangs the entire system (100% CPU usage, mouse cannot be moved anymore) and takes roughly 2-5 minutes.

Assumption: It occurs only in the Release-compile, hence it is connected with the loading information in the splash screen.

System environment OS: WindowsXP SP3 Framework: .NET 3.5 SP1 (with all patches) Graphics: ATI Mobility FireGL V5200

Strange: The effect does *not* occur when a second monitor is connected and Windows runs in extended desktop mode.

Change History (16)

comment:1 Changed 12 years ago by Sören Rinne

I agree to the above mentioned things and can add, that it also happens when I run my own compiled CT2 in VS.

When I have a monitor attached to my laptop, this problem doesn't occur. I have a Lenovo T61.

comment:2 Changed 12 years ago by Thomas Schmid

I'm running CoreDev release version right now on a Lenovo T61 - without monitor attached. I can't reproduce the problem - maybe only in pulbic solution?

comment:3 Changed 12 years ago by Sören Rinne

You're right. On the current solution I don't have the problem anymore.

Current beta installer on website not checked.

comment:4 Changed 12 years ago by Thomas Schmid

hmm - i don't really know what solved the problem. removed some compiler directives so that splash screen is shown in debug and release version. And it is not topmost any more. @Arno: is the problem solved for you, too? I think than we could close this defect.

comment:5 Changed 12 years ago by Arno Wacker

Unfortunately it's not completely gone for me on the Lenovo T60p:

Without a connected monitor I got the following behaviour with current trunk:

  • Running it from within Visual Studio (F5) in Debug and Release mode I get a normal start, effect is not detectable, however, also the starting "Progress-Bar-in-Splash" is not shown (in both: Debug and Release).

  • Running it with a direct click on the just compiled exe (i.e. outside Visual Studio) in Debug mode is the same as within Visual Studio, i.e. no progress bar and normal start. Starting the Release-exe however, exhibits the effect. Here the progress-bar is shown and again the system is almos unresponsive until CrypTool is done loading.

With a connected monitor all (in all above cases) runs normal (fast).

It seems to me, that it is directly connected to the initial progress bar: whenver this is shown, the system blocks/hangs until CrypTool is done.

Therefore, unfortunately, I think we cannot close this ticket yet. @Sören: Can you repeat all of the above tests with your setup? I.e. test within and without Visual Studio (always without external monitor) - and observe if the progress-bar shows. Is there a case where the progress-bar shows and it runs normel fast?

comment:6 Changed 12 years ago by Sören Rinne

Same here.

F5/Debug -> No ProgressBar -> Fast Running .exe from Debug -> No ProgressBar -> Fast

F5/Release -> No ProgressBar -> Fast Running .exe from Release -> ProgressBar -> Very very slow

comment:7 Changed 12 years ago by Sören Rinne

(sry for the confusing formatting in my last comment. I will try that again:)

Same here.

F5/Debug -> No ProgressBar -> Fast
Running .exe from Debug -> No ProgressBar -> Fast

F5/Release -> No ProgressBar -> Fast
Running .exe from Release -> ProgressBar -> Very very slow

comment:8 Changed 12 years ago by Thomas Schmid

Sorry i forgot to commit my changes. Updated the files now (At revision: 468) Could you please retest the behavior?

comment:9 Changed 12 years ago by Sören Rinne

Same problem as before.

comment:10 Changed 12 years ago by Matthäus Wander

The problem seems to be caused by the call(s) to Dispatcher.Invoke in CrypWin.InitStatus.AddMessage(...) and SetProgress(...).

comment:11 Changed 12 years ago by Matthäus Wander

Added command line argument -nosplash as workaround. Does this help?

comment:12 Changed 12 years ago by Sören Rinne

I now have Windows 7 and the problem is gone (without using -nosplash). So I can't tell what's with Win XP.

PS: CT2 starts *much* faster on Win 7 than it did on Win XP. Must be a better integration of .NET 3.5

comment:13 Changed 12 years ago by Arno Wacker

The commandline argument successfully masks the effect. Hence, the effect can be circumvented with the "-nosplash" commandline argument. However, now there is a certain period of time, in which CrypTool seems to do nothing (actually the plugins are loaded, but without the status-screen this cannot be seen) - this could irritate some users. Therefore this workarround is mostly for developers.. the core problem ist not solved.

On the other side.. Win7 is pushing WindowsXP away, hence not sure about how this problem still is.

comment:14 Changed 12 years ago by Matthäus Wander

Priority: Should be doneMust have

comment:15 Changed 12 years ago by Arno Wacker

Resolution: fixed
Status: newclosed

(In [1177]) CrypWin:

  • Fixed slow start of CrypWin on some architectures - this finally closes #73!
  • Refinements of the start-screen, tested only on WinXP, Vista and Win7 test pending.
  • Added new command line option "-silent" to completeley deactivate all log messages (also the log-window is hidden)
  • Small refactoring for logging-methods

Samples:

  • Added samples for P2P-based bruteforcing of AES. Does njot work yet, since the P2P Manager crashes when connected with AES (due to a serialization erro of the longer KeyPattern...)

New binaries for CrypWin and AnotherEditor.

comment:16 Changed 10 years ago by Matthäus Wander

Milestone: CrypTool 2.0 RELEASE
Note: See TracTickets for help on using tickets.