D3D11 CreateDeviceAndSwapChain makes Visual Studio unuseable - visual-studio

Hi all I have a pretty odd problem.
When I step through my code from the beginning of the program its fine but when I get to the section in my code to create the device and swap chain Visual Studio starts lagging for input and becomes unuseable. My mouse also gives really delayed response. The only way to stop it is to ctrl+alt+del and close Visual Studio.
Here's the code up to the line in question.
HRESULT hr = S_OK;
RECT rc;
GetClientRect((*pWindowHandle), &rc);
UINT width = rc.right - rc.left;
UINT height = rc.bottom - rc.top;
UINT createDeviceFlags = 0;
#ifdef _DEBUG
createDeviceFlags |= D3D11_CREATE_DEVICE_DEBUG;
#endif
D3D_DRIVER_TYPE driverTypes[] =
{
D3D_DRIVER_TYPE_HARDWARE,
D3D_DRIVER_TYPE_WARP,
D3D_DRIVER_TYPE_REFERENCE,
};
UINT numDriverTypes = ARRAYSIZE(driverTypes);
D3D_FEATURE_LEVEL featureLevels[] =
{
D3D_FEATURE_LEVEL_11_0
};
UINT numFeatureLevels = ARRAYSIZE(featureLevels);
DXGI_SWAP_CHAIN_DESC sd;
ZeroMemory(&sd, sizeof(sd));
sd.BufferCount = 1;
sd.BufferDesc.Width = width;
sd.BufferDesc.Height = height;
sd.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
sd.BufferDesc.RefreshRate.Numerator = 60;
sd.BufferDesc.RefreshRate.Denominator = 1;
sd.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
sd.OutputWindow = (*pWindowHandle);
sd.SampleDesc.Count = 1;
sd.SampleDesc.Quality = 0;
sd.Windowed = TRUE;
sd.Flags = DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH; // allow full-screen switching
for (UINT driverTypeIndex = 0; driverTypeIndex < numDriverTypes; driverTypeIndex++)
{
m_driverType = driverTypes[driverTypeIndex];
hr = D3D11CreateDeviceAndSwapChain(NULL, m_driverType, NULL, createDeviceFlags, featureLevels, numFeatureLevels,
D3D11_SDK_VERSION, &sd, &m_pSwapChain, &m_pd3dDevice, &m_featureLevel, &m_pImmediateContext);
if (SUCCEEDED(hr))
break;
}
I've got a feeling it might have to do with visual studio rather than the project since the D3D11 sample projects also do the same. They run fine but as soon as you try to pause or break VS throws a wobbly.
I've already tried repairing my version of VS2013 Update2
Is there something that can help me?
Output from the debug folder
Build started 02/11/2014 16:24:14.
1>Project "C:\Users\luckielordie\Source\Repos\3dtut2\Tutorial02_2010.vcxproj" on node 2 (Build target(s)).
1>ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /I..\..\..\DXUT11\Core /I..\..\..\DXUT11\Optional /ZI /nologo /W4 /WX- /Od /Oi /Oy- /D WIN32 /D _DEBUG /D DEBUG /D PROFILE /D _WINDOWS /D D3DXFX_LARGEADDRESS_HANDLE /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /arch:SSE2 /fp:fast /Zc:wchar_t /Zc:forScope /openmp- /Fo"Debug\\" /Fd"Debug\vc120.pdb" /Gd /TP /analyze- /errorReport:prompt D3D11.cpp
D3D11.cpp
Link:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\link.exe /ERRORREPORT:PROMPT /OUT:"C:\Users\luckielordie\Source\Repos\3dtut2\Debug\D3DApplication.exe" /INCREMENTAL /NOLOGO d3d11.lib d3dcompiler.lib dxguid.lib winmm.lib comctl32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /manifestinput:"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\Include\Manifest\dpiaware.manifest" /DEBUG /PDB:"C:\Users\luckielordie\Source\Repos\3dtut2\Debug\D3DApplication.pdb" /SUBSYSTEM:WINDOWS /LARGEADDRESSAWARE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\Users\luckielordie\Source\Repos\3dtut2\Debug\D3DApplication.lib" /MACHINE:X86 /SAFESEH /SAFESEH:NO Debug\Tutorial02.res
Debug\D3D11.obj
Debug\D3D11ResourceBuilder.obj
Debug\Game.obj
Debug\GameObject.obj
Debug\main.obj
Debug\Model.obj
Debug\Shader.obj
Debug\Window.obj
Tutorial02_2010.vcxproj -> C:\Users\luckielordie\Source\Repos\3dtut2\Debug\D3DApplication.exe
1>Done Building Project "C:\Users\luckielordie\Source\Repos\3dtut2\Tutorial02_2010.vcxproj" (Build target(s)).
Build succeeded.
Time Elapsed 00:00:01.42
EDIT:
On that line in the Output I get a line
A thread <threadnumber> has exited with code 0(0x0)

I had exactly the same problem and it was solved by updating video drivers (I have nVidia GeForce 660, and now I use 344.75, I installed it using "clean" option). Previous driver was 335 or something. Also if it doesn't help, try disabling nVidia ShadowPlay (it didn't help me though), I think some problem can lie there, if it installs some keyboard hook inside D3D.

Related

Get the Current QueryPerfromanceCounter Value in Debugger

Is there a way to get the current value of QueryPerformanceCounter while in the debugger? We use QPC in our code for all time values, but without the "current" time we have no way to calculate the time delta for these values.
I am Not sure what you are looking for ?
if you want to Call QueryPerformanceCounter from an extension you can use the code below compile an extension and bang it out
#include <engextcpp.cpp>
class EXT_CLASS : public ExtExtension
{
public:
EXT_COMMAND_METHOD(qpc);
};
EXT_DECLARE_GLOBALS();
EXT_COMMAND(qpc,"","")
{
LARGE_INTEGER perfcount = {0};
BOOL res = QueryPerformanceCounter(&perfcount);
if(res) {
Out("perfcounter is %I64X\n",perfcount.QuadPart);
}
}
compiled and linked with as x64 from dev cmd prompt
cl /LD /nologo /W4 /Ox /Zi /EHsc /I"C:\Program Files (x86)\Windows Kits\10\Debuggers\inc" %1.cpp /link /EXPORT:DebugExtensionInitialize /Export:%1 /Export:help /RELEASE
usage
.load .\qpc.dll
.chain
Extension DLL chain:
.\qpc.dll: API 1.0.0, built Wed Feb 2 02:56:14 2022
[path: F:\src\wdbgexts\qpc\qpc.dll]
0:000> !qpc
perfcounter is 6A0832C7711
0:000> !qpc
perfcounter is 6A0841BE77B
0:000> !qpc
perfcounter is 6A084A392A8
0:000>
if opening a shell is acceptable then you can also use powershell stopwatch
0:000> !qpc;.shell -ci "$$" "cmd /k powershell -Command 'perfcounter is {0:X}' -f [system.diagnostics.stopwatch]::GetTimestamp()"
perfcounter is 3E79CEF8BE
perfcounter is 3E79F0D3F7
C:\WINDOWS\system32>.shell: Process exited
0:000>

How to control clang default include path

My copy of clang tries to include Visual Studio header files, this is the output of clang -v hello.cc
clang version 9.0.0 (https://github.com/llvm/llvm-project.git 4f93b8b56f5982d19b8b55b8c575887c17e15588)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: D:\llvm-project\build\Release\bin
"D:\\llvm-project\\build\\Release\\bin\\clang++.exe" -cc1 -triple x86_64-pc-windows-msvc19.21.27702 -emit-obj -mrelax-all
-mincremental-linker-compatible -disable-free -disable-llvm-verifier -discard-value-names -main-file-name hello.cc -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -v -resource-dir "D:\\llvm-project\\build\\Release\\lib\\clang\\9.0.0"
-internal-isystem "D:\\llvm-project\\build\\Release\\lib\\clang\\9.0.0\\include"
-internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.21.27702\\ATLMFC\\include"
-internal-isystem "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.21.27702\\include"
-internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.17763.0\\ucrt" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.17763.0\\shared"
-internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.17763.0\\um" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.17763.0\\winrt"
-internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.17763.0\\cppwinrt" -fdeprecated-macro
-fdebug-compilation-dir "D:\\llvm-project\\build\\Release\\bin" -ferror-limit 19 -fmessage-length 120 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.21.27702 -std=c++14 -fdelayed-template-parsing -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o "C:\\Users\\krono\\AppData\\Local\\Temp\\hello-19d364.o" -x c++ hello.cc
clang -cc1 version 9.0.0 based upon LLVM 9.0.0svn default target x86_64-pc-windows-msvc
#include "..." search starts here:
#include <...> search starts here:
D:\llvm-project\build\Release\lib\clang\9.0.0\include
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\ATLMFC\include
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\shared
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\winrt
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\cppwinrt
End of search list.
Presumably this was because I made some mistake when I built it (I built it with Visual Studio). How can I make it include the correct header files? I'm talking about a permanent solution rather than just overriding the include search path each time I compile.
Some background on this. I am trying to build a C++ program with clang and I get multiple multiply defined symbol errors, like this
error LNK2005: "bool const std::_Is_integral<bool>" (??$_Is_integral#_N#std##3_NB) already defined in ...
std::_Is_integral is a name defined in the Visual Studio <type_traits> header file. I believe that if I could get clang to include <type_traits> from the LLVM libcxx project this error would go away.
I have been hit by the same problem on several open source project myself. I do not have the answer but I can possibly give more details on the nature of the problem:
1) The problem is coming from STL headers in VS2019, which use the following constructs:
$ grep -r _Is_integral *
include/xtr1common:// STRUCT TEMPLATE _Is_integral
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral = // determine whether cv-unqualified type _Ty is integral
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral = false; // determine whether cv-unqualified type argument is integral
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<bool> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<char> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<signed char> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<unsigned char> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<wchar_t> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<char16_t> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<char32_t> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<short> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<unsigned short> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<int> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<unsigned int> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<long> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<unsigned long> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<long long> = true;
include/xtr1common:_INLINE_VAR constexpr bool _Is_integral<unsigned long long> = true;
include/xtr1common:_INLINE_VAR constexpr bool is_integral_v = _Is_integral<remove_cv_t<_Ty>>; // determine whether _Ty is integral
The behavior is related to how "if constexpr" is evaluted by the compiler. According to the standard it should be supported from C++17, but MSVC compiler silently supports it when running (in default) C++14 mode.
clang-cl on the other hand does not generate C++17 code, when run in C++14 mode, so it generates all those exported symbols and then lets the (MS) linker complain about them.
The solution I found so far (which may or may not be applicable depending on the project) is forcing clang-cl into C++17, which then compiles the constructs using "if constexpr" correctly (with no symbols).
The other temporary workaround may be using /force:multiple in linker flags to force the linking. Since their values should not change, the multiple definition should not be problem, but it is also suboptimal.
Apparently, MS is aware of the problem, but do not want to change the library.
https://developercommunity.visualstudio.com/content/problem/426829/xtgmathh-and-other-microsoft-include-files-use-if.html
Concerning the usage of Clang's "native" STL, I would expect one would need to use also "native" clang (i.e. not clang-cl, which is drop down replacement for MSVC). How this might go then however I have no idea.

Sharing static library between .dll(runtime loading) and .exe

I have a .lib library which provides APIs which have global variables like file/device handles, these APIs are going to be used by the application(.exe) by linking with .lib statically. The application does some initialization using APIs provided by .lib (like opening device/file etc) and loads the .dll during run time to perform writes and reads to the device/file using APIs provided by .lib. The problem is when I link the static library with both .exe and .dll they have different copies of libraries and the initialization done by the application is not retained when .dll is opened during run-time (since .dll and .exe seem to be working with their own copy of .lib). This problem is solved when I make .dll instead of static library and export all APIs and import them in .exe and .dll.
But I want to make the .exe standalone without any .dll dependencies except for run-time .dll .
Here is sample code for scenario
main.c (.exe)
#include <stdio.h>
#include <windows.h>
#include "static_lib.h"
typedef void (*FNPTR)(void);
FNPTR functionname;
int main(){
HINSTANCE hLib;
LPTSTR dllname = "dynamic.dll";
hLib=LoadLibrary(dllname);
if(hLib==NULL)
{
printf("Unable to load dll %s\n", dllname);
return 0;
}
functionname=(FNPTR)GetProcAddress((HMODULE)hLib, (LPCSTR)"dyn_main");
if((functionname==NULL))
{
printf("unable to load test function %s\n", dllname);
FreeLibrary((HMODULE)hLib);
return 0;
}
printf("Var in main: ");
test_func();
printf("calling dyn_main:");
functionname();
printf("back to main:");
printvar();
FreeLibrary((HMODULE)hLib);
return 1;
}
static_lib.c (static library)
#include <stdio.h>
#include <windows.h>
#include "static_lib.h"
int var; //can be file or device handle
int test_func(){ //initializes the device
change_var();
printvar();
return 1;
}
void printvar(void){ //write/read device/file
printf("%d\n",var);
return;
}
void change_var(void){ //opens device/file
var = 1;
return;
}
static_lib.h
#ifndef _STATIC_LIB_H_
#define _STATIC_LIB_H_
#if defined (DLL_EXPORT)
#define DLL_IMPORT_EXPORT __declspec(dllexport)
#else
#define DLL_IMPORT_EXPORT __declspec(dllimport)
#endif
DLL_IMPORT_EXPORT void change_var(void);
DLL_IMPORT_EXPORT void printvar(void);
DLL_IMPORT_EXPORT int test_func();
#endif
dynamic.c (.dll)
#include <stdio.h>
#include <windows.h>
#include "static_lib.h"
__declspec(dllexport) void dyn_main(void){
printvar(); //uses the device
return;
}
The command line for compiling with dynamic linking is
cl /c /nologo main.c dynamic.c
cl /c /nologo /DDLL_EXPORT static_lib.c
LINK /nologo /DLL static_lib.obj
LINK /nologo /DLL dynamic.obj static_lib.lib
LINK /nologo main.obj static_lib.lib
The output is:
main.exe
Var in main: 1
calling dyn_main:1
back to main:1
But when I make a static library and link with .exe and .dll
cl /c /nologo main.c dynamic.c static_lib.c
LIB static_lib.obj
LINK /nologo /DLL dynamic.obj static_lib.lib
LINK /nologo main.obj static_lib.lib
The output is
main.exe
Var in main: 1
calling dyn_main:0
back to main:1
And in real scenario the program crashes as it is invalid device/file handle inside .dll.
Is there anyway to export APIs into .dll from .exe without linker giving unresolved symbol error and maintaining only one copy of static library used by .dll and .exe?
I have searched for the problem and I found this: Dynamic Loading of my DLL with Static Lib in Windows Environment
It says we cannot do this in windows environment. But I want to make sure before thinking of other alternatives.

How to name a thread in Windows Performance Analyzer?

I was trying to display the names of threads in Windows Performance Analyzer (WPA) (under Windows 8.1). This tool has a column called "thread name".
I followed the famous MSDN article:
http://msdn.microsoft.com/en-us/library/xcb2z8hs(v=vs.110).aspx
However, looks like it doesn't work in WPA. And according to a 3rd-party document, only Microsoft’s Visual Studio and WinDbg debuggers support this exception.
So how can I name a thread so that its name can be displayed in WPA?
Starting in Windows 10, version 1607, you can use the SetThreadDescription() API, which is now supported in xperf/WPA:
https://randomascii.wordpress.com/2015/10/26/thread-naming-in-windows-time-for-something-better/
You can also vote for support for it to be added to other Microsoft tools here:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/17608120-properly-support-native-thread-naming-via-the-sett
Dont have wpa installed handy so cant answer your query but thanks for
the question it never occurred to me that this could be used native code too
could come in handy
#include <windows.h>
#include <stdio.h>
const DWORD MS_VC_EXCEPTION=0x406D1388;
//EmptyBlock,Constant in__except() and lpparam not used in ThreadProc
#pragma warning( disable : 6312 6322 4100 )
#pragma pack(push,8)
typedef struct tagTHREADNAME_INFO {
DWORD dwType; // Must be 0x1000.
LPCSTR szName; // Pointer to name (in user addr space).
DWORD dwThreadID; // Thread ID (-1=caller thread).
DWORD dwFlags; // Reserved for future use, must be zero.
} THREADNAME_INFO;
#pragma pack(pop)
DWORD WINAPI ThreadProc( LPVOID lpParam ) {
int ch = 0; while(ch != 'y') { ch = getchar(); } return 0;}
void SetThreadName( DWORD dwThreadID, char* threadName) {
THREADNAME_INFO info; info.dwType = 0x1000; info.szName = threadName;
info.dwThreadID = dwThreadID; info.dwFlags = 0;
__try {
RaiseException( MS_VC_EXCEPTION, 0,
sizeof(info)/sizeof(ULONG_PTR), (ULONG_PTR*)&info );
}
__except( EXCEPTION_CONTINUE_EXECUTION) { }
}
void main (void) {
HANDLE hThread = NULL;
printf("\n\n\n=======Creating Thread And Naming It================\n\n\n");
if (( hThread = CreateThread(NULL,NULL,ThreadProc,NULL,NULL,NULL)) != NULL) {
SetThreadName(GetCurrentThreadId(), "\n\nMy New Shiny Thread\n\n");
WaitForSingleObject(hThread,INFINITE);
printf("Named Thread Terminated Main is terminating\n");
CloseHandle(hThread);
}
}
compiled linked and windbagged vcpp event seems to handle this exception in windbg
wonder what MAGIC Dword dbce handles
dir /b
compile.bat
threadname.cpp
type compile.bat
#call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86
cl /Zi /nologo /W4 /analyze *.cpp /link /RELEASE
compile.bat
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
threadname.cpp
dir /b *.exe
threadname.exe
cdb -c "sxe -c \"~*;gc;\" vcpp;g;q" threadname.exe
0:000> cdb: Reading initial command 'sxe -c "~*;gc;" vcpp;g;q'
=================Creating Thread And Naming It===================
(f84.db4): Visual C++ exception - code 406d1388 (first chance)
. 0 Id: f84.db4 Suspend: 1 Teb: 7ffdf000 Unfrozen "
My New Shiny Thread
"
Start: threadname!mainCRTStartup (00401642)
Priority: 0 Priority class: 32 Affinity: 1
y
Named Thread Terminated Main is terminating
quit:

Embedding Tcl in a C program

I am trying to create a simple c++ console app that calls the nagelfar syntax checker on a script. I followed the directions here: http://wiki.tcl.tk/19919 , adding the tclstub85.lib to my input, adding the tcl lib directory to my additional libraries, and adding my header directory as well. Linking fails with:
main.obj : error LNK2001: unresolved external symbol _tclStubsPtr
This is my command line for linking:
/OUT:"C:\Users\######\Documents\Visual Studio 2005\Projects\Nagelfar\Release\Nagelfar.exe"
/NOLOGO /LIBPATH:"C:\Tcl\lib" /MANIFEST
/MANIFESTFILE:"Release\Nagelfar.exe.intermediate.manifest" /DEBUG
/PDB:"c:\users\######\documents\visual studio 2005\projects\nagelfar\release\Nagelfar.pdb"
/OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT C:\Tcl\lib\tclstub85.lib
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
This is the full source code, which I can compile and run fine in Linux using g++:
#include <stdlib.h>
#include <stdio.h>
#include <tcl.h>
#include <string.h>
Tcl_Interp * tcl_interp ;
char fileToCheck[] = "test.tcl";
char dbFile[] = "syntaxdb.tcl";
int main () {
int code, argc;
const char **argv;
char command[1024];
char *results = NULL;
tcl_interp = Tcl_CreateInterp();
Tcl_SetVar2(tcl_interp, "::Nagelfar", "embedded", "1", 0);
code = Tcl_EvalFile(tcl_interp, "nagelfar.tcl");
Tcl_LinkVar(tcl_interp, "::Nagelfar(chkResult)", (char *)&results, TCL_LINK_STRING);
sprintf(command, "synCheck %s %s", fileToCheck, dbFile);
code = Tcl_Eval(tcl_interp, command);
printf("Raw Result: \r\n %s\r\n", results);
code = Tcl_SplitList(tcl_interp, results, &argc, &argv);
{
int i;
for (i = 0; i < argc; ++i)
{
printf("%d/%d: %s\r\n", i+1, argc, argv[i]);
}
}
Tcl_Free(results);
return 0;
}
Solved my own problem: I had x64 ActiveTcl but was linking a 32 bit project. Using the x86 ActiveTcl distribution fixed my issues.
Your error message tells us that you are expecting a stub table (Tcl's goes by the name tclStubPtr once all the macros are expanded), which in turn says that defining the preprocessor symbol USE_TCL_STUBS. That symbol is for use in the case where you are writing a library that is providing extra functionality to Tcl. However, in the case where you are writing a main application that calls functions in the Tcl library — such as “run this code” — you can't (easily) use the stubs mechanism as you'd be needing the stub table before Tcl is in a position to be able to provide it to you.
The fix is to not define USE_TCL_STUBS and to link against the main Tcl library (probably C:\Tcl\lib\tcl85.dll on your system) instead of tclstub85.lib. (I don't know enough about setting up Visual Studio to say what the details of that configuration are.)
You should also add this line to your code before the call to Tcl_CreateInterp():
Tcl_FindExecutable(NULL);
That call is used to allow the Tcl library core to initialize itself, doing little things like getting the memory manager and filesystem interface layer working.
Solved my own problem: I had x64 ActiveTcl but was linking a 32 bit project. Using the x86 ActiveTcl distribution fixed my issues.

Resources