This is likely due to a difference in the working directory for your program when run from Visual Studio versus launched "normally." Visual Studio sets the working directory for a process it launches. When you launch the executable normally, the working directory is the directory containing the executable itself.
Since relative paths begin at the working directory, this changes where you end up effectively looking for data files. Consider the following typical directory structure:
X/Projects/Game
Game.sln
Game.vcproj <-- your project file
Source/
Assets/
Shader.fx <-- your shader
bin/
Debug/
Release/
Game.exe <-- your compiled executable
You probably refer to your shader file in code via the relative path "Assets/Shader.fx" (or similar, adjusted for your actual directory structure).
Visual Studio uses the project directory as the working directory by default for C++ projects when launching your process. In the case of the above structure, that is the path X/Projects/Game and consequently your relative path reference to the shader is X/Projects/Game/Assets/Shader.fx. This path exists, so everything runs normally when launched from the IDE.
But if you double-click the compiled Game.exe from explorer.exe your working directory is X/Projects/Game/bin/Debug and consequently your relative path reference becomes X/Projects/Game/bin/Debug/Assets/Shader.fx. That path doesn't exist, and until it does, your game won't run properly.
The solution is to ensure that the shader and other assets get copied to the output directory of the executable (maintaining their directory structure, if applicable). One way to do this is via custom build steps in your project, for example by launching a batch file to copy the relevant files or using a direct invocation of something like robocopy. Visual Studio has a fairly robust set of macros that can be used to make construction of this build step easier, so you could do something like:
robocopy $(ProjectDir)/Assets $(TargetDir) /S