Continuation on PassthroughAPP questions for Igor

Referencing post:
http://groups-beta.google.com/group/microsoft.public.inetsdk.programming.webbrowser_ctl/msg/8d598d9c14f95c53?dmode=source&hl=en

Igor wrote:

"Beware multithreading. URLMon has this nasty habit of spinning worker
threads, not even bothering to initialize COM on them, and calling APP
methods on those threads. If you try to raise COM events directly from
such a thread, bad things happen (random crashes, events being lost).

You are only guaranteed to be on the main STA thread in two cases.
First, in methods of interfaces that were obtained with
IServiceProvider, such as IHttpNegotiage::BeginningTrans­action or
IAuthenticate::Authenticate. Second, you can call
IInternetProtocolSink::Switch with PD_FORCE_SWITCH flag in
PROTOCOLDATA::grfFlags, eventually URLMon will turn around and call
IInternetProtocol::Continue on the main thread. "

Igor,

Your help was very useful in the past, but we are experiencing some
random 'crashes' that have to do with 'memory not being able to be
written'. If you remember, what I've done is replaced out the Dialog
components of your sample APP which a COM wrapper which initializes the
instances for http and https. Then within some of passthrough methods
(those in TestApp.cpp) I am calling methods in my wrapper class. This
is fairly similar to how you were writing the "request" and "response"
headers to the text boxes in the dialog box of your sample. The only
difference is those methods don't write to a text box, they raise COM
events that a .NET client uses.

I am raising calling methods from within UnlockRequest, CTestAPP::Read,
ReportProgress (when BINDSTATUS_SENDINGREQUEST) which in turn raise COM
events.

Things work great, most of the time, but occasionally I notice strange
behavior / crashes.

In my opinion I could be doing two things wrong:

1) Handling of the pv pointer from Read to .NET seems to be
problematic. I was unable to get the void * out of COM in any direct
way, so I construct a SafeArray copy in the data from pv to that array,
send the SafeArray out through COM, and then copy the SafeArray data
back into pv. With this method certain things still seem flaky, even
a simple cast of this safearray in .NET causes exceptions. I am able
to make yet another copy within .NET work with it and copy it back in
but this does seem to be a lot of work for something such as this.

If you have any suggestions on a alternative way to expose the *pv of
Read through COM, it would be appreciated.

2) The other thing could be the fact that I am not doing anything
regarding your multithreading concerns you voiced some time ago
(because I didn't understand exactly what I should do).

I don't know if any of the methods I mentioned above require me to do
something special, such as calling "IInternetProtocolSink::Switch". If
so, I'm not sure what calling "Switch" buys me, and if I'm suppose to
do it all the time or only in certain cases.

If you have any suggestions, they would be much appreciated!

.