Mixed Mode applications stuck at 100% cpu after startup

Hello,

Someone I work with is using some of my applications. (Written in mixed managed c++ and native C++ via VS2008) Upon installing my latest application he cannot run that application and now any application of mine he had installed before cannot be ran. The failure shows itself as ~100% CPU usage but nothing else happens. The application shows up in task manager but never shows the form. Using remote debugger I discovered that the application seemed to be stuck in a loop before it ever reaches main. I also noticed that the last module loaded is always winmm.dll. Which seemed odd to me because I do not intentionally link to this. I believe that it may be linked to from the standard C++ libraries but I am not certain. There is a microsoft knowledgebase article KB942152 which seems similar to the problem but has very little description of its manifestation and the solutions do not exactly seem to fit this case.

It is worth noting that I test all of my applications on a "test pc" with no compiler/ide setup. The test pc has the same applications of mine installed including the new one from the same installers and there is no problems on that pc. The applications are also installed on several other pcs some with IDE and some without and no one else has had this problem. One last note is that when I run remote debugger on the machines that do not have the problem winmm.dll never appears to be loaded.

Any Ideas?

UPDATE:

Some Client Machine Specs: (IE one failure is occuring on)

Windows Xp SP3 with .net 1.1 .net 2.0 and .net 3.5
2ghz single core with 1 gb ram.

So far I have been unable to reproduce the error on any other machine or link it in any way to the kb mentioned in the post. I am not directly linking to winmm.dll but I am using MSVCM90.DLL which apparently indirectly links to it.

I can't really say that winmm is causing the problem but the problem only seems to occur on this machine and this machine is the only one that I ever see winmm.dll loaded on. Winmm is also always the last module loaded.

I will post if I find a solution or any other information. Even if no one responds the information may be useful to someone down the road.

Another update (and a name change for the thread)

It turns out this doesn't appear to have anything to do with Mixed Mode code. I created two bare bones applications. One is C# obviously managed and another in C++ native. The C++ native application runs just fine but the .NET C# application has the same symptoms as my mixed mode applications. So a new question.... does anyone know why .net applications (previously working) would do this on a single machine. I attempted to repair .net framework 2.0 on the machine but it hangs up in the middle of the repair when I try. The user claims that my application cause the problem. I am checking it out but I'm not really convinced.

Any suggestions?

Another update:

I removed and reinstalled the .NET framework on the machine. (Not as trivial as it sounds actually those who haven't should try it sometime). This had absolutely no affect. After reinstalling the framework (2.0 to be exact) the same problem occurs.

So....

.NET applications go to 100% cpu as soon as they are started.

A reinstall of the .NET framework seems to rule out a corrupt framework.


I may have to resort to doing a repair install from xp cd because the guy really needs his machine running.

I would rather debug the problem to find out the root cause but I may not get the chance.

I am taking a backup of the registry and repairing from the XP cd. Hopefully I will get a chance to look through the registry file and figure out exactly what happened if its even in there. If I find anything more I will post but it isn't likely that any other evidence will show up.

Doing the re-install repair fixed the problem....

At this point I really don't think my msi installer could have caused the problem. This application
registered NO other objects. In fact it doesn't really need the installer to run at all. I just used it because it's easier to make short cuts and add to the clients Programs list. (Also to check for and install pre-reqs) In this case no pre-reqs were needed because they were already on the client system. Of course everyone in the office still thinks my application caused the problem.... Go Figure.

Does anyone know of a reason that an msi installer (made with Visual Studio 2008 setup project) could cause this kind of problem?

Rulings:

- Was not a mixed mode problem after all.
- No concrete evidence that points to my app as the culprit other than it was installed about the same time.