Yes, typically debug builds will initialize memory on the stack (i.e local variables) whereas release builds won't. Unitialized local variables in release builds will therefore have random (not really, but as good as) stack garbage in them, and if you try to use such a variable without initializing it you'll get weird behaviour. Sometimes your program might even work, sometimes it won't and sometimes when it crashes it may crash in a random place rather than at the actual faulty code.

The best way to avoid this is to get in the habit of always initializing local variables when you declare them. The sooner you get in this habit the better, and you'll find that once you start seeing the benefit of it, an unitialized local variable will really jump out at you while you're reading code.

So, instead of:

int i;

mytype *foo;

You need to be using:

int i = 0;

mytype *foo = NULL;

You should have probably not waited so long before setting up a release build either. Making it a regular - though not necessarily frequent - part of your testing process can help catch a lot of release build bugs at an earlier stage.

Usually the most difficult part for beginners to get right is handling dependencies. In Windows it is usually up the individual application to create an installer that will package up any required DLL's (along with any other files), and then copy them to the appropriate locations. Since you're using /MD your app will depend on the MSVC++ runtime DLL, which you can't assume will be present on an end-user's machine. This means you either need to package it with your program, or have the user install the DLL using the redistributable package that Microsoft provides (which you can also package instead your installer if you wish, and then launch silently). The redistributable that you use depends on the version of Visual Studio being used, so you'll have to make sure that you use the right one.

External libraries may also require DLL's or runtime redistributables to be installed, depending on what you're using. For D3D11 you will need to install the redistributable package if you're using any version D3DX. Also if you're using a version of D3DCompiler from the Windows SDK, then you'll want to package that DLL with your app. I'm not sure if the version of bullet you're using is a DLL, but if it is you'll need to package that as well. Same goes for the Oculus SDK.