Exception from HRESULT using SpeechLib

[Snakebite05]

Hello all.

I have been using the beta releases of VB .NET 2005 (I must say that theyre very good), and I recently switched over to the final build, complete with the .NET framework 2.0. Now, I was using the MS SpeechLib to speak using the Text-To-Speech engine thru the speakers. This was working fine throughout the beta builds, but when I switched over to the final, it has problems. See, randomly, whenever I call the speech library, my app crashes with the following error:


Exception from HRESULT: 0x80045063

Now, I searched the internet and found absolutely zilch for that above error. This, by the way, was the output of "Ex.MEssage" string using that Try...Catch deal. The output of "Ex.InnerException" is null. There doesn't seem to be a pattern here; it could be any time throughout the app that it could crash. It's a simple command-line app, and just speaks text through the speakers. Im really not sure why this is happening. Any help would be appreciated. Thanks.

[jmcilhinney]

Try calling ToString on the exception, which will give you maximum information including the call stack.

[penagate]

An HRESULT is not an exception, it is a return code which under certain circumstances causes a (very helpful as usual) exception to be thrown.

Can you post the code you are using to call the library (which I guess must be a COM library) ?

[conipto]

Also, if you can get it to crash in the IDE, you can click on the "Call stack" window and post that text (if jmcilhinney's suggestion doesn't show you the call stack)

Bill

[Snakebite05]

An update.

I tried running inside the IDe and waiting for a crash. I really this error is out of my league entirely. Below is the error:

ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x1af778 to COM context 0x1af8e8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.


This is total greek to me - I'm just a hobby coder. Any help would be much appreciated. THanks.