# Windows Modelbuilder startup problem, python init
**URL:** https://discourse.kitware.com/t/windows-modelbuilder-startup-problem-python-init/327
**Category:** Build & Install
**Created:** [October 3, 2019, 2:19pm UTC](https://discourse.kitware.com/t/windows-modelbuilder-startup-problem-python-init/327 "2019-10-03T14:19:42Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@aron.helser](https://discourse.kitware.com/u/aron.helser)
#### Post date: [October 3, 2019, 2:19pm UTC](https://discourse.kitware.com/t/windows-modelbuilder-startup-problem-python-init/327/1 "2019-10-03T14:19:42Z")
Wondering if anyone has seen this before. I’m building with VS2019, which I don’t think has been done before.
I’m seeing a heap-corruption crash in Paths.cxx:
```
std::string Paths::pathToLibraryContainingFunction(void (*func)(void))
{
return boost::dll::symbol_location(*func).parent_path().string();
}
```
called by
```
static std::string pythonLibraryLocation = Paths::pathToLibraryContainingFunction(Py_Initialize);
```
It’s a RelWithDebInfo build.
Debugging, it seems like the path retrieved is garbage, the parent\_path() ends up being empty, and then when the temporary objects are cleaned up, the heap corruption is detected.
I’ve tried to set PATH and PYTHONPATH to point to the superbuild python, but it didn’t change the behavior.
Anyone seen something similar before?
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [October 3, 2019, 2:27pm UTC](https://discourse.kitware.com/t/windows-modelbuilder-startup-problem-python-init/327/2 "2019-10-03T14:27:34Z")
> [@aron.helser](#):
>
> I’m building with VS2019, which I don’t think has been done before.
1. I would try constructing a minimal working executable (i.e. outside of SMTK) that calls `boost::dll::symbol_location` to make sure your installation of boost is returning what you’d expect. You can have the function point to any symbol you like within the compilation unit for reference.
2. Using the above example, add python as a compile-time dependency and point the boost function to the python symbol.
3. Take this example and put it into SMTK’s testing (still not using SMTK’s libraries, only its build infrastructure) to make sure you still have boost doing what you’d expect.
If I had to guess, I would guess the above will show an issue when you change the symbol to something in python’s library. If that’s the case, then this is a MSVC2019 + python issue.