dotnet framework: ApplicationException in TimerBase.AddTimerNative method. -- dotnet framework

ApplicationException in TimerBase.AddTimerNative method.

Jan Obrestad
6/29/2007 2:02:38 PM

dotnet framework: Hello.
I'm developing a module in .Net for a program that's made in c++. With a
new version of this program I started getting strange exceptions in my
module.

I found out that the exceptions originated in the AddTimerNative method
of the TimerBase class. Using Reflector I've found out that this is an
unmanaged native method in the framework itself. I'm using .Net 2.0.

I've had two different messages on the ApplicationExceptions:
"Error in the application" (very helpfull....) and "Overlapped I/O
operation is in progress."

Does anyone have some idea what the problem might be?

To clarify, the developers on the main application say they have changed
nothing about how they load and execute .NET modules.

To make things even more confusing, it's not consistent, sometimes I get
this exception upon starting on the module, other times that works fine.

And these exceptions only show up in release builds of the software, it
suns fine in debug mode on my machine.

Any help in finding out what on earth is happening would be appreciated.

Re: ApplicationException in TimerBase.AddTimerNative method.

Jan Obrestad
7/2/2007 12:34:58 PM

Just to clarify.
I was wrong when I said it runs fine in debug mode. I was running an
older version of the program that do not have this problem. As soon as I
used the new version the debug build also failed.

So I've narrowed the cause down to some change made in the main program,
but this is a large program with many modules so it would be nice if
someone could give a suggestion of what to look for.

[quoted text, click to view]

Re: ApplicationException in TimerBase.AddTimerNative method.

Jan Obrestad
9/24/2007 12:00:00 AM

Some of my colleagues managed to find a solution to this.
The problem was this code from an unmanaged dll that was used by the
program:

BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
g_hModule = (HINSTANCE)hModule;

case DLL_THREAD_ATTACH:
CoInitialize(NULL);
break;
case DLL_THREAD_DETACH:

case DLL_PROCESS_DETACH:
::CoUninitialize();
break;
}
return TRUE;
}

After this was fixed to
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
g_hModule = (HINSTANCE)hModule;
break;
case DLL_THREAD_ATTACH:

break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:

break;
}
return TRUE;
}

the problem was gone.
The problem is calling CoInitialize(NULL) for every new thread.

Hope this might be a help to anyone having the same problem.

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet framework group.