Are you saying a thread in the *native* DLL is getting suspended? If so
then that's not possible as the GC knows nothing about the threads and
cannot and will not affect them. THis sounds a lot more like a pinning
problem to me. Like your native thread is using some data from the managed
app and when GC happens that managed data is getting moved during a
compaction (which doesn't happen with every GC and would explain why it
doesn't happen when you manually call collect). With what little info we
have so far, my bet is you're passing in a variable that is getting used in
the native DLL - probably being sent by reference - that you're not pinning.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com




"sid" <mailsid******.com> wrote in message
news:25261b1a-081c-4e1a-aefc-43eb9ef4373e@d4g2000prg.googlegroups.com...
> Hi
>
> I have an application written in VB.NET for windows mobile 2005
> device. In addition I have 2 unmanaged DLL's written in C which the VB
> app uses.
>
> The app runs absolutely fine until the system garbage collector gets
> triggered, at which point one of my DLL's (in which I create a
> separate thread for some sound recording task) thread gets suspended
> and never gets up after that. At this point my application just stops
> working.
>
> Is there any way I can mark my THREAD as GC-SAFE so that GC just
> bypasses it during its sweep operations.
>
> The intriguiing part is, if I manually trigger the GC with the
> following lines (executing these lines quite regularly)
>
> GC.Collect()
> GC.WaitForPendingFinalizers()
> GC.Collect()
>
> then it seems to be working fine, even when the GC is virtually always
> on.
>
> Anyone has any say on this please advise as I am not convinced with
> calling the GC commands from within the application.
>
> Cheers
> Sid