Some others have already posted good links to profilers -- redgate's profiler is particularly good.
Here's a link to a good article on finding leaks in .Net:
http://blogs.msdn.com/b/ricom/archive/2004/12/10/279612.aspx
Here's a great blog -- the author is a support engineer at MS (these people are really good programmers that work in windebug all day to find problems). A great many of her articles are about trackign down memory leaks. Most of her examples are asp.net, but most of the techniques should apply to Windows apps as well:
http://blogs.msdn.com/b/tess/archive/2006/01/23/516139.aspx
Also, be aware that you might not have a real leak. By design, the .Net garbage collector does not immediately release memory. It does periodic collections that are triggered by various events (I don't think that MS has published a complete list of the things that will cause the garbage collector to fire). I do know that one of the triggers is low memory conditions, and another trigger can be a memory allocation. If nothing triggers it, the GC will not collect.
That means that you can start a Winform .net app, let it eat a bunch of memory (and then release it), and then leave it sitting all night long. If the computer has been idle for the whole time, the GC may not have fired, and the app still might own a lot of memory. When something happens to trigger the collection, memory will be freed. It's very common that people report that .net apps appear to be slow to release memory as a result of this behavior.
Go ahead and profile -- you might have a leak, but also be aware that this might be behavior by design. Either way, good luck!