It really depends on what you think the problem is. If you're running on .NET 1.1 and you suspect fragmentation, you should probably start by reading this article, which describes how the situation arises:
http://www.simple-talk.com/dotnet/.net- ... ject-heap/
If you can get your application running on .NET 2.0 for the purposes of profiling, you will have an easier time of debugging this issue as the profiler can provide more information.
Fixing these problems tends to be rather involved. You can find which objects are on the large object heap using the filter panel: almost certainly this will be some arrays. You will need to either change the order in which these are allocated so that all the long-lived arrays are allocated early on in the program's lifetime, or work out how to substitute arrays that don't end up on the large object heap.
If the problem is actual unmanaged memory usage, the memory profiler won't be able to help if the component with the leak is itself unmanaged. If you aren't using your own or any third-party unmanaged components, this is fairly unlikely, however. If the problem is .NET components that reference unmanaged objects, you just need to find the leaked .NET components and fix them to reduce the unmanaged memory usage. You can do this by looking at the instance counts. I posted a possible strategy for this here:
http://www.red-gate.com/MessageBoard/vi ... hp?t=12658