I don't think that the memory profiler will make any noticeable difference to the way that weak references behave.
The biggest difference that you will see with the profiler attached to a desktop app is that it will disable concurrent garbage collection. Until you click 'take snapshot' for the first time, there won't be any other major differences in application behaviour except that garbage collections will take longer (but only noticeably longer after the first snapshot has been taken in most cases)
You can edit your applications config file to disable this mode yourself and see if you get the same effect. See http://msdn.microsoft.com/en-us/library ... f8(v=VS.80
).aspx for details on the setting.
The most likely cause that I know of for this kind of problem is large object heap fragmentation. Garbage collection timing can affect how this turns out, so the change in mode could explain the behaviour you're seeing. You can tell for sure if the Large Object Heap bytes counter is very high at the point when your application crashes (outside the profiler).
You might be able to solve this issue by adding a GC.Collect() to the appropriate part of your code: it's not ideal because there will be a performance hit. The memory profiler can help a bit with identifying which objects are likely to be responsible: take two snapshots a reasonable distance apart (long enough that you'd expect to have seen an issue) and set the filters to show new objects that are on the large object heap: it's likely that you need to force a collection whenever these objects are freed up. Alternatively, you might want to cache and recycle them, or rewrite the code so that it only uses small arrays.