I'm developing a program unrelated to Messenger, in my program I can single step down to the first call to CreateWindowEx() and everything runs at full speed. But when I step over the CreateWindowEx() call it takes about 10 seconds to complete - it appears that loading MsgPlusLoad1.dll is what's taking the time, unload MsgPlus using the task manager and everything is fine. I get the same pause if I just run my program from with-in the IDE (Visual Studio 2003).

It appears to be some strange interaction between Visual Studio's debugger and MsgPlus - if I execute my program using Ctrl-F5 it runs at full speed.

Anybody got any ideas???

MsgPlus version 3.62.146

Have a look at the following threads:
Problem for SW developers with last version "3.62.146"
Visual Studio & MsgPlusLoader

I've tried following the advise on those two threads, but to no avail.

Hook method set to "Default - Forced" and the registry "Addins" entry is blank, additionally the only place the MsgLoader.DLL is mentioned is in the Software/Msgplus2/Patchou section.

Any more suggestions?

I'm also having the same problems (CreateWindow hanging for 'a few' seconds, while VS debugger is loading symbols for MsgPlusLoader.dll)  as the op. I've already tried all the solutions mentioned in the threads listed above - without success. I tried basically the same steps as the OP :
- Configuring Messenger Plus in default mode, rebooting a few times (still having this problem)
- Configuring Messenger Plus in default/forced mode, rebooting, again, a few times (still having this problem)

As Messenger Plus! is not in "alternate" hooking mode, there's really nothing in the AppInit_Dlls key @ [HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows]. Besides, I searched my entire registry for "MsgPlusLoader.dll" and "MsgPlusLoader1.dll", and the only result was in the messenger plus registry entry ("MsgPlusLoader.dll" in FileNameLoader key).

Also, I don't know if there's a difference, but sometimes the CreateWindow call stalls the debugger loading "MsgPlusLoader1.dll" instead of "MsgPlusLoader.dll".

Of course, running my program without the debugger (Ctrl F5) eliminates the problem.

Note that it's really the CreateWindow(Ex) call that makes the debugger stall (isolated it trough breakpoints).

I'm using VC08 (Visual Studio Express), Plus! 3.6.146, Windows XP SP2.

Any possible solutions are appreciated.

The best solution I've found is to terminate the msgplus.exe in the task manager - seems to make no difference the plus's functionality and it stops the hang

I'll definitely try that. Still kind of a hack though.

well, the fact that your debugger is searchign for the symbolds of msgplus is normal and that will always take time. The real question I guess is: does it take extra time each time you create a window or only the first time?

I'm pretty sure this is a debugger issue.

It only takes time on the first CreateWindow call, which seems logical, since after the call, the symbols are supposedly "loaded", so the debugger doesn't "waste time" to search for them. I only had problems with this debugger with messenger plus so far. At startup, the debugger loads [or try to load] all the symbols corresponding to the dll's used by my application (kernel32.dll, winmm.dll and so on - most of them don't have symbol files). The point is, the whole loading doesn't even take a tenth of a second, whereas the search for msgplusloader/msgplusloader1.dll's symbols can take up to 15 seconds (and usually not less than 5 or 6, which is quite annoying).

This problem has only appeared since [I think it's 3.60.144, well, I had this problem before upgrading to 3.62.146].

I'm using visual studio 8.0. To be sure it was'nt the debugger, I tested creating a window in a blank visual studio 2003 project (as far as I know, the only link between the two debuggers is that they're from microsoft), and the problem is still here. Are you sure there's no hook when I set msgplus to Default or Default-forced ? Anyway, I'd be happy to test again with any debugger you like (remember that the hang happens when the debugger tries to load msgplus's dlls). Thanks for your reply.

Update: If that may help, this is what my debugger can say when I watch the modules loaded :

Note that your module is only loaded at runtime, on the first CreateWindow call.

Yet another update : the function "MessengerPlusGlobalHook" from msgplus...1.dll is called whenever I use "CreateWindow" (verified, just set up a breakpoint in assembly code). If that's normal, feel free to ignore this remark.

Thank you wtbw, now everything's back to normal. Heh, I'll take care not to use network paths for pdb's as from now. Thanks again, now I can use Messenger Plus while debugging !

Why the hell do you have this path embedded in the release builds of the software? this path is not even valid on my own computer.

Well then, sorry about that, I'll make sure this does not happen with future updates. Now at least we know where the problem comes from, I just have to find why the hell VC created such a path .

How did you manage to edit out the string in the DLL. Ive found the string, and tried changing it, which worked for a bit and now visual studio seems to be moaning about it.

Ive tried just deleting the string inside, but i get an error saying that it cant find the Loader dll now, when the file is definately there.

There are two copies of it though, one in windows/system32 and one in programfiles/messengerplus. Which one is the one which is used? or does it need both? They are both the same file, yet both seem to be locked when plus runs.

Its annoying waiting 10 seconds at the start of any debugging session!

Is it possible for anyone to send their version with the string cut out which will work?

Many Thanks in advance

Have changed the first char to 00, and it works nicely. 33920 is right!

I had just installed visual studio 05 and was wondering why i was getting nice error messages and nothing worked. Is all good now!

It also took me longer to write that post, than it did for you to get it, reply to it, and for my "someone has replied to your post" email to come in!

Jaw droppingly fast! Thanks

DLLs (the odd little .. *&$!*), seem to be able to be locked... but you can still rename them.

I have a VB program i wrote which kills messenger and messenger plus... waits for me to say "okay", then it starts them again. I used it when i was writing plugins for plus. Was a handy tool.

I first copied the dll to another name, then I managed to rename the DLL first to blahMsgPlusLoader.dll, even though that was locked. I renamed the copy to MsgPlusLoader.dll again. You can now edit this version since it isnt locked yet ( preferably edit it while its still "Copy of ....") Then when anything tries to find it again by name, it finds the new edited version.

I hadnt thought of the "replace first char with null" idea though! Am doing programming in c++ at the moment with string classes and c style strings. I should have got that one really! ^_^

Thanks again

Note: that is supposed to be fixed in version 3.63.