MySQL Workbench 已停止工作 错误模块名称: KERNELBASE.dll 异常代码: 0xe0434352 程序无法正常启动：（ 0xc000007b）

搜索这样的标题，相信你也很绝望啊。

我是在学习MySQL时候遇到的这个问题，心想图形化多么美好，结果一装上就遇到了这个问题。

其他同样报错信息的情况本文同样适用，不一定非是Workbench。

我装的版本不重要，我相信这不是某个版本的问题，首先声明：

重新安装或者更新 Visual Studio ，.Net 运行环境，或者其他什么运行环境，以及卸载重装，更换版本无果后，以下解决方案才对您适用。

长而无用预警，想要快速解决请直接翻底部。

细心的朋友可能还记得，当时安装MySQL配套组件的时候，多多少少会有一些小问题：比如某个组件装不上啊，失败啊，之类的。要是没有任何问题也没有弹出任何对话框，那么接下来的方案可能也不适合您。

如果记性好，当时可能有这么一个对话框一闪而过，并不影响安装：

如果您不记得了，大可以卸载掉Workbench重新安装一遍，流程如下：

这是管理器，先卸载：

然后安装：

无论你是否出现那个错误框，你都会顺利完成安装：

好，如果这一切都做了，你也从来没有见过那个报错的框，那请离开这个页面继续探索。如果的确报了这个错，就留下来，和我一起探索。

首先，对话框是在说 python.exe 应用程序无法正常启动（0xc000007b）

有朋友可能看到这，“噢，支持环境问题啊”。啪，鼠标一点，离开了，那是不对的。

Actually，我已经装了几乎所有版本的开发环境，问题还是问题。

如果有人抱着侥幸心理继续装几个的话，也是没用的。

摸瓜要顺藤，先去看看Workbench的安装目录。

明显能看到python 27的可执行文件。

又有朋友“噢，python的环境啊……”，也是不对的。

事实上，就在不远的隔壁文件夹，我很早之前就装好的py2.7运行十分良好，没有任何问题。

于是我开始第一次尝试（本文全程直播情况下编写，犯错也会写出来），备份的情况下，把WB的python文件复制给根正苗红的py27，结果，出现了开头那个熟悉的对话框。更离奇的事情还在后头，两个python.dll的信息：

不能说是===吧 ，也至少是== 了。这意味着这俩都是经典版的2.7.6，算我运气好。

于是就拿这个可执行文件开刀吧（我猜是治标不治本的举措）。把先前备份的py27的正统文件，复制给WB目录。啊对忘了说，WB目录下的大0.5KB。

结果简直是相当的优秀（别急着关网页）：

很好，我的原生python27也沾染了这乖张气息，实在是无话可说。

这下我又陷入了思考，发现了一个有趣的现象：

无论是哪个python.exe，把它们复制出去，不在根目录下，任何地方运行，都会报上面这个错误。而这，也绝对是导致Workbench一开就崩溃的根本原因。

也就是说，缺少了某个文件，或者某些文件，是产生错误的祸根。

这个提示也就是在说：“运行所需要文件不充足。”

喜感的是，这两个python都是一样的版本，但是原生的就能用。

得证：缺的绝对不是py27的运行环境，但WB的这个版本里的确是用的py27。

于是我有了一个大胆的想法（当然也是欠妥的，我不管，先给我把WB打开了再说）：

由于有MySQL的安装向导在那，所以咱底气足，说重装就能重装。所以我干脆，用原版的python2.7.6,完全覆盖进WB的根目录下。

我不傻，这么做肯定是不能完全解决问题的，被修改的.exe，肯定加了什么料。

但是，容许我侥幸一下（为了方便我直接复制了一份WB）：

需要格外注意的是简单粗暴复制粘贴肯定药丸，这里的python文件，除了根目录下零星的几个文件，可执行文件和dll之外，再没了。根目录下多了个叫做python的文件，打开后内容和结构也不尽相同。所以，需要有技巧的复制粘贴。

根目录下的，直接有则改之无则加勉（一共替换两个，一个是可执行的，一个是一模一样的dll。估计没戏）~其他目录，自己看着改，名字一样就覆盖替换合并。

DLLs 和lib 两个文件夹，替换内容如下：

pyexpat.pyd 原生文件较小

select.pyd 原生文件较小

……200多个文件

site-pacages  合并，很和平，没有覆盖.其他文件没有用肉眼发现，看结构也不会有，试一次（用WB的.exe）:跑不起来！同一个问题！

BUT！换成原生.exe  却奇迹般跑起来了! 

但是然并卵，WB依然一副死相。但好歹是个探索的过程。

这也反映出一个问题：WB里的python似乎是个傻子，根本不知道自己要什么环境。

下来继续聚焦问题：

少了这个KERNELBASE.dll文件，一般是配置文件出的故障，学习可知WB的配置文件：

MySQLWorkbench.exe.config 和WBControls.dll.config

里面的内容完全一样

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
</configuration>

那就改着试试

改了改也没什么用

我想，自己再单独装一个的话应该会没有问题的：

于是我下载个官网的安装包（其实是骗你的，我早些时候下了没用而已），官网在哪我就不说了。

重新覆盖安装到了对应目录，然后问题就解决了，嗯。

思考：这个问题注定是一个路径配置的问题，问题至少但不限于在python的配置上，可能涉及的所有文件和程序都“不知自己身处何处”，导致了无法引用正确的开发环境而“找不到文件”。再深究，肯定是installer在安装的时候没有给程序传递一个正确的路径，而是传递了某种不恰当的路径。继续归根结底，那肯定是WB的程序在编写的时候对这一种被上级installer 安装的模式没有一个恰当的应对，导致了最终的配置错误。

可以这么想：用installer装的WB，自己认为自己在“D盘”“U盘里”“DVD里”“飞碟上”，都是有可能的，所以它就不会用正确的方式表达自己的请求（偶尔认为自己在D盘的也能成功）。这个问题也被称为  0xe0434352  会让人误以为开发环境没配置好。

展望：作为一个普通用户，冲进根目录手撕源代码，我做不到。（大神也不见得个个能把exe撕开就看就改吧？），而且目录里那么多引用，大小环境，想要重新过一遍，不现实。所以明智的举措，最好就是WB的开发者升级关于配置的代码，以及作为用户，应该机智地绕开installer，让WB以一种独立形态，用它配套的小installer去正确安装。获取的方法，可以是官网，也可以是手动进大installer的目录下去薅（hao）。

一句话式总结：去官网下载最新版本的msi文件覆盖到原来的目录，不要用MySQL自带的安装器再重复安装了，没有用。

写给其他软件或者程序报错的朋友：这是安装（移动）时产生的错误，归根结底在于配置文件没有正确设置，导致程序无法准确定位。解决方案，采用其他安装方式（不是机械化的重装重启），换一个版本或者installer。如果是移动甚至跨机器移动，一定要尽可能保证环境的一致性，比如开发环境的安装目录，以及移动后程序本身的目录。手撕配置文件也是好的解决方式，如果是自己的程序，很推荐这么做。