You haven't indicated whether this is a cloak that you're trying to build, or whether it's a pre-built product, or what, so I'm doing some random guessing here. But <enter lecture mode>.
Explosions in dForce are almost always caused by one of two things - self-intersections, or issues with the settings on the surface. To understand what's going on in the non-self-intersection case, you have to understand how dForce simulates garments.
Think about the mesh in your garment. Ideally, it's a whole bunch of rectangles (quads). The way dForce models things is by pretending that all the vertices are connected together using springs. So, the four edges of your quad are four springs, but there are also springs connecting the diagonals and connecting vertices farther apart. This is how they model things like bending, skew, etc.
Now, when dForce is running, what it does is figure out how much tension is in each spring (based on the distances of the vertices), and then shift the vertices a bit based on the net force on the vertex from all its springs, recalculate the distances and the forces, lather, rinse, repeat. The problem is that if the springs are too stiff, a small amount of movement by the points creates a large amount of force on a vertex. This causes it to move a lot, but that stretches other springs a lot, so THEY cause a lot of force in another direction, and so you end up building up a whole ton of energy as they oscillate back and forth, and then next thing you know, you've got your topographical map. This kind of instability is inherent in almost any discrete simulation (i.e. break it down into, say, one iteration per millisecond and calculate the effects for the next millisecond). Because the simulation is not, and cannot be, 100% continuous, small errors creep in, and under the wrong situations, they amplify quickly.
So, things you can do:
- Ideally, when the garment is in its default rest position, all the "springs" should be at their default length, so that they don't start out with a whole lot of "stretch." Otherwise, you've got a slingshot cocked and ready. There's a setting in dForce simulation settings (and, for the life of me I can't find it right now) that basically says "at the beginning of the simulation, assume that the springs are at their default length."
- The "collision offset" value is important. This basically says "this vertex is supposed to be this far away from anything else in the scene." The problem is that if a lot of the vertices in your mesh start out closer together than this, you have a lot of movement "desired" right from the get-go. Daz warns you about this - you get a whole list of "vertex X is at DIST which is less than collision offset" warnings. There's such a thing as a mesh that's too dense for optimum dForce operations. If you're getting a lot of these warnings, maybe reduce the collision offset.
- The stiffer the spring, the greater chance of an explosion. Two alternatives - reduce the stiffness, or else change the simulation settings so that there are more - possibly MANY more - iterations per second. (Increase the number of subframes or the number of iterations per subframe or both). The issue is that if a spring is under a lot of tension because it's very stiff, if you make the simulation work more times per second, the amount of movement per iteration will be smaller, and dForce will realize that the force from the spring is diminishing rapidly. As a gross example, if you have one iteration per second, the vertex will move one second's worth at the velocity imparted by the spring at the beginning of that second, which could cause it to overshoot a LOT compared to reality. If you have 1,000 iterations per second, it'll only move one millisecond's worth before the force, velocity, etc., is recalculated. The time step for a given spring stiffness is very, VERY important in making sure that the simulation doesn't become unstable.
- Increase the damping. Because dForce works with springs, the springs can easily get into a situation in which they oscillate. By increasing the damping, you cut down on this. Basically, damping sucks energy out of the springs, and it's the buildup of energy that causes the explosion.
The bottom line is that there is no "one good value" for the dForce settings. The "correct" settings for stiffness and damping depend a great deal on the density and shape of the mesh being simulated. So, what's "silk" for one mesh might be "denim" for another mesh, and "explosion" for a third mesh.
I'm sorry that there's not one single "canned" answer to this, but my experience with dForce is that it's very sensitive to the settings, particularly the stiffness settings, and that there's no "predictable" way to choose them other than trial and "explosion error."
