如何诊断 MS 访问崩溃 [英] How to diagnose MS access crashes
问题描述
我们有一个用 Access 编写的自定义程序，其中有奇怪的崩溃.我们添加了错误处理，可以记录和通过电子邮件发送发生在我们自己的代码内部的任何崩溃，这使我们能够修复我们生成的大多数错误，但有时崩溃发生在我们的代码之外.
We have a custom program written in Access that has odd crashes in it. We have added error handling that records and emails any crashes that happen inside of our own code and that has allowed us to fix most errors that we have generated, but sometimes the crashes happen outside of our code.
我们发现在 2013 年突然出现的一个例子——我们有一个表单在编辑某个字段中的数据后会崩溃——新条目很好，但在创建记录后进行任何编辑都会导致MS Access 完全崩溃和关闭.我们花了一些时间并最终发现我们的某些代码正在强制表单移动到下一条记录，尽管该字段是行中的最后一个字段，但 Access 本身也在尝试移动到下一条记录.这自 2007 年以来一直存在于系统中，但在 2013 年开始导致程序关闭.
An example of one that we found that cropped up new in 2013 -- we have a form that would crash after editing data in a certain field -- new entry was fine but any edits after the record was created would result in a full crash and shutdown of MS Access. We spent time and eventually tracked down that some code of ours was forcing the form to move to the next record, this field was the final field on the row though so Access itself was also attempting to move to the next record. This had been in the system since 2007, but started causing program shutdowns in 2013.
有什么方法可以捕获和诊断 MS 访问中的程序级崩溃?
Windows 事件查看器仅显示以下内容:
is there any way to trap and diagnose program level crashes inside MS access?
The windows event viewer only shows the following:
错误的应用程序名称:MSACCESS.EXE，版本:15.0.4454.1501，时间戳:0x50a35ef4错误模块名称:MSACCESS.EXE，版本:15.0.4454.1501，时间戳:0x50a35ef4异常代码:0xc0000005故障偏移:0x00116452错误进程 ID:0x1398错误的应用程序启动时间:0x01ce6e665043d8be错误的应用程序路径:C:Program Files (x86)Microsoft OfficeOffice15MSACCESS.EXE错误模块路径:C:Program Files (x86)Microsoft OfficeOffice15MSACCESS.EXE报告编号:6cfcb0eb-da62-11e2-8966-842b2b86f028
Faulting application name: MSACCESS.EXE, version: 15.0.4454.1501, time stamp: 0x50a35ef4 Faulting module name: MSACCESS.EXE, version: 15.0.4454.1501, time stamp: 0x50a35ef4 Exception code: 0xc0000005 Fault offset: 0x00116452 Faulting process id: 0x1398 Faulting application start time: 0x01ce6e665043d8be Faulting application path: C:Program Files (x86)Microsoft OfficeOffice15MSACCESS.EXE Faulting module path: C:Program Files (x86)Microsoft OfficeOffice15MSACCESS.EXE Report Id: 6cfcb0eb-da62-11e2-8966-842b2b86f028
推荐答案
这是一个旧线程，但它是 Google 上最热门的结果之一，所以我想我会给出答案.当您收到Access 遇到问题需要关闭"时，您可以采取哪些步骤.通常在事件日志中你会看到:
This is an old thread, but it came up as one of the top results on Google so I thought I would give an answer. What steps can you take when you get "Access has encountered a problem and needs to close". Usually in the event log you will see:
Faulting application name: MSACCESS.EXE, version: 15.0.4869.1000, time stamp: 0x57e12b41
Faulting module name: MSACCESS.EXE, version: 15.0.4869.1000, time stamp: 0x57e12b41
Exception code: 0xc0000005
解决这些问题可能会令人沮丧.以下是我采取的行动清单，从侵入性最小到侵入性最大.我不只是发明这些修复程序 - 多年来，我亲眼目睹了每个修复程序都解决了问题.
These can be frustrating to troubleshoot. Below is the list of actions I take, from least invasive to most invasive. I am not just inventing these fixes - over the years I have personally witnessed each fix resolve the issue.
反编译数据库
您指出反编译每个版本是政策.好的政策 - 但在每次出现错误后都明确地执行.原因是您可能正在修复核心问题，但由于容器损坏而没有注意到.
You indicated that it is the policy to decompile every release. Good policy - but do it explicitly after EVERY time you get an error. The reason is because you may be fixing the core problem, but not noticing due to a corrupt container.
- 我创建了一个使用/decompile"开关加载数据库的快捷方式.
- 双击此快捷方式时按住 shift 键，这样会跳过任何自动运行并直接进入导航窗口.
- 加载数据库后，您需要单击压缩和修复"按钮.在数据库重新加载时再次按住 shift.
- 现在去编译代码并保存.这就是我用于反编译的过程.
测试计算机内存
特别是如果崩溃仅限于一台或两台机器 - 这样做.
检查事件查看器.是否有很多描述应用程序崩溃的错误"消息，并且故障模块不同?如果是这样，那么如果不是损坏的 Windows 安装，则很有可能是内存问题.
Especially if the crashes are restricted to one or two machines - do this.
Check the event viewer. Is there quite a few "Error" messages which describe an application crash, and the faulting module is different? If so then odds are good that if it isn't a corrupt windows install, you are looking at a memory issue.
我相信有很多出色的内存测试器，但我鼓励您使用适当的测试来捕获丢失的位.MemTest86 很老，但很好.有 当前版本 和一些同样好的 分叉.
I am sure there are many great memory testers, but I encourage you to use a proper test that will catch dropped bits. MemTest86 is an oldie but a goodie. There is the current version and some equally good forks.
开始测试并让它在工作时间内运行.我在建筑物中的电源不好导致内存错误，所以保持变量不变.
Start the test and let it run during working hours. I have had bad power in the building cause memory errors, so keep the variables the same.
从表单中删除二进制数据
有时崩溃发生在单个表单或报告中.如果它是损坏的二进制数据，那么崩溃应该发生在不同的计算机上，有不同的用户.如果是这种情况，请按照以下步骤操作.(仅限高级用户)
Sometimes the crashes occur in a single form or report. If it is corrupt binary data, then the crashes should be occurring on different computers, with different users. If this is the case then follow these steps. (Advanced Users Only)
在即时窗口中将对象保存为文本.
In the immediate window save the object as text.
Application.SaveAsText acForm, "MyForm", CurrentProject.Path &"MyForm.txt"
Application.SaveAsText acForm, "MyForm", CurrentProject.Path & "MyForm.txt"
重命名原始表单项(例如重命名为 MyForm_Bak)
Rename the original form item (e.g. rename to MyForm_Bak)
- 查看文件.
- 将会有以Parameter = Begin"开头的行，并且有几行编码的二进制数据，以一行由End"组成的行结束
- 当您找到这些行之一时，您需要(包括)删除从开始到结束的所有行.
- 应该删除的参数有:NameMap、PrtMip、PrtDevMode、PrtDevNames、PrtDevModeW、PrtDevNamesW
- 所有这些块都应该出现在表单控件定义之前
在 Access 中的即时窗口中，将表单加载回
In Access, on the immediate window, load the form back in
Application.LoadFromText acForm, "MyForm", CurrentProject.Path &"MyForm.txt"
Application.LoadFromText acForm, "MyForm", CurrentProject.Path & "MyForm.txt"
反编译/压缩修复/重新编译
Decompile / Compact Repair / Recompile
去掉OLE 对象"字段
如果您在 Access 中存储了图像或其他数据，那么您应该找到更好的方法.OLE 数据存储时，会根据存储它的计算机上的软件(和软件版本)进行存储.当另一台计算机在表单上显示该 OLE 对象数据，但没有安装确切的软件/版本时 - 您经常会崩溃.
If you have images or other data stored in Access itself then you should find a better approach. When the OLE data is stored, it is stored according to the software (and version of software) on the computer storing it. When another computer goes to display that OLE Object data on the form, but doesn't have the exact software / version installed - you quite often wind up with a crash.
如果您要存储图像数据，则更好的方法是存储文件名，并将图像保存到标准位置.较新版本的访问具有本机控件，使之成为可行的方法.
If you are storing image data, then a better approach is to store the filename, and instead save the images to a standard location. Newer versions of access have the native controls to make this the way to go.
重建整个数据库
这项工作量很大，所以我会把它留到你用尽所有其他选项时.仅当所有用户都出现问题时才需要执行此操作.如果不是所有用户都发生这种情况，那么它就不是一个损坏的数据库.
This is a lot of work, so I would save this for when you have exhausted all other options. You only need to do this if the problem is occurring for all users. If it isn't occurring for all users, then it is not a corrupt database.
与删除二进制数据的步骤类似，您将从头开始重建数据库.当我到达这一步时，我处于完全偏执的模式.也许它有点仪式化，但我做每件事都一丝不苟，没有捷径，而且非常小心，不通过直接复制或导入/导出来保留"腐败.作为我的最后立场，我认为这从来没有解决过这个问题.谢天谢地，自从 Access 2000 出现以来，我就不必这样做了.
Similar to the steps in removing binary data, you are going to rebuild your database from scratch. By the time I reach this step I am in all-out-paranoid mode. Maybe its a bit ritualistic but I do everything meticulously with no short cuts and great care in not "preserving" the corruption through direct copying or import/export. As my last stand, I don't think this has ever failed to resolve the issue. Thankfully I haven't had to do this since the days of Access 2000.
- 创建一个新的访问数据库容器.
- 不要使用导入/导出功能
- 表格:
- 对于旧访问容器中的每个表，在新容器中创建一个新表.从设计视图中，复制/粘贴字段定义.
- 将旧数据导出为 XML 或 CSV，然后从那里导入.
- 进入原始查询中的 SQL 视图，将 SQL 文本复制并粘贴到新数据库的查询中.
- 使用 Application.SaveAsText 函数导出表单/报告
- 从表单中剥离二进制数据并进行审核
- 使用 Application.LoadFromText 函数重新导入它们
- 重新创建宏.
- 在 Access 2007 及更新版本中，使用新的宏系统，您只需打开宏，全选 (Control + A) 并粘贴到空白记事本文档中即可.再次从记事本复制并粘贴到新访问容器内的空白宏中
- 选择所有代码 (Control + A) 并将 (Control + V) 粘贴到新的数据库容器中
- 自从出现数据宏以来，我就不必这样做了，但您可以使用 SaveAsText/LoadFromText 函数从表中导出数据宏.
当一切都完成后 - 您应该拥有一个非常干净的数据库容器.
When all is said and done - you should have a very clean database container.
从测试中删除其他变量
网络损坏
不要从网络加载客户端.将它放在本地驱动器上并从那里运行.
Do not load the client off of a network. Put it on the local drive and run it from there.
企业构建
如果您在使用计算机构建"的公司环境中，并且在反编译、测试内存和剥离二进制数据方面没有成功 - 然后拒绝进行进一步的测试，直到 IT 团队可以为用户提供测试仅安装了 Windows、Office 和 Service Pack 的计算机.我通常更喜欢自己安装，所以我知道我可以信任它.所有软件和更新都应手动安装，而无需使用无人值守安装.不要在这台机器上安装杀毒软件.
If you are in a corporate environment that is using "computer builds" and have had no success with Decompiling, Testing Memory, and stripping Binary data - then refuse to do further testing until the IT team can provide the user with a test machine that has only Windows, Office, and Service Packs installed. I usually prefer to do the install myself so I know I can trust it. All software and updates should be installed by hand without using unattended installs. Do not install antivirus on this machine.
我让 IT 部门完全出于 F.U.D.和不合理 - 如果这是您遇到的情况，请在帮助我帮助您"上下文中洗手.
I have had IT departments refuse this out of sheer F.U.D. and unreasonableness - if this is what you encounter then wash your hands of the issue under the "Help me help you" context.
弱电
如内存部分所述 - 电源波动会导致计算机错误.如果数据库位于工业建筑中 - 那么请尝试使用提供清洁电源的电源调节器或 UPS(关闭电池，而不是关闭通过金属氧化物压敏电阻的主电源)
As mentioned in the memory section - power fluctations can cause computer errors. If the database is in an industrial building - then try to get your hands on a power conditioner or a UPS that provides clean power (off the battery, not off the main passing through a Metal-oxide Varistor)
另外，检查插入电源条或插座的电源线.确保规格和电压规格足够.我这样说是因为 IT 部门经常将电源线插在站台上，然后将机器卸下.多年后，他们使用更强大的电源，但还没有关闭电缆.它有所作为.如有疑问，请带上一根新的、更粗的电缆.
Also, check the power supply cable that is plugging into the power bar or outlet. Make sure that the gauge and voltage specs are sufficient. I say this because IT departments often leave power cables plugged in at the station and just remove the machine. After many years, they are using beefier power supplies, but haven't switched out the cable. It makes a difference. When in doubt, bring a new, thicker cable.
附录
自从最初发布此内容以来，我遇到了一些新内容.在转移到 Access 2016 时，我多次受到打击的是 ODBC 驱动程序.如果您的数据库在 Access 2013 下运行良好，但在 Access 2016 中非常可靠地崩溃，那么问题可能出在 ODBC 驱动程序上.立即尝试找出是否有更新的驱动程序.如果没有成功，则通过创建新数据库并在 VBS 中进行 ODBC 调用来确认它是否是 ODBC 驱动程序.如果您遇到相同的崩溃 - 它的驱动程序.如果没有更新的驱动程序，您只需将其保留在 2013 年.我在使用带有几个数据库的 PostGreSQL ODBC 驱动程序时遇到了这个问题.
Since originally posting this I have ran into a few new ones. One that has hit me multiple times is the ODBC drivers when moving to Access 2016. If you have a database that works fine under Access 2013, but crashes quite reliably in Access 2016, then the issue may be the ODBC driver. Off the hop, try to find out if there is an updated driver. If no success there, then confirm whether it is the ODBC driver by creating a new database, and making an ODBC call in VBS. If you get the same crash - its the driver. Without an updated driver, you'll just have to keep it at 2013. I encountered this with PostGreSQL ODBC driver with a few databases.
这篇关于如何诊断 MS 访问崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
