<p>I have a COM dll written in vb6. When I try to create a new object of a class module from this dll I get a Run timer error 430: Class does not support automation or does not support expected interface. The interesting thing is that this happens only from outside the IDE, when I am debugging from within the IDE there is no error thrown and the new object of the class is created successfully. What can be the cause?</p>

<p>In general I occasionally get these kind of errors in COM dlls. What is the best way to debug COM issues? How can I know the path of the dll that is being used when a program is running?</p>

This is almost certainly a versioning problem, sometimes known as "DLL hell".
The background is that the .NET world is explicitly designed to let interfaces evolve while keeping the same name. But in the COM world, interfaces are considered to be immutable.
When you're working within the IDE, Visual Studio is creating a new COM Interop wrapper for the COM dll every time you run your solution. But unless you release and replace your entire solution every time, including a brand-new COM Interop wrapper, you're going to run into a versioning issue, where the .NET code is expecting one COM interface but seeing a different one.
EDIT
: For some reason, I assumed that you're trying to use the COM component from a .NET component. If the entire solution is actually VB6, then Mr Conley's solution is the recommended approach.
Here's a good link
that discusses the problem.