How I Got MongoDB Running Reliably with Docker After Repeated Windows Service Crashes

My journey from a missing data directory and Windows Error 1067 to a containerized database development environment.

Sometimes, the hardest part of software development is not writing code. It is getting the development environment to work reliably.

Recently, I decided to use MongoDB for local development on my Windows 10 laptop. My plan was simple: install MongoDB Community Server, connect my applications, create databases and collections, and continue developing my projects.

Initially, everything seemed to work perfectly.

I could start the server, connect through MongoDB Compass, create databases, and import collections. But after restarting my laptop, MongoDB would crash. I spent hours trying different configurations, inspecting logs, changing data directories, and restarting the Windows service.

At one point, I even started deleting the database directory just to get MongoDB running again. That workaround made the problem appear to disappear, but it was obviously not a reliable solution.

Eventually, I decided to try Docker. After moving MongoDB into a container, I added data, restarted my laptop, and tested the setup again. This time, MongoDB was still working and my data was available.

Here is the complete story of how I reached that point, the errors I encountered, what I learned from the logs, and why Docker became my preferred approach for local database development.

1. My Development Environment

Before discussing the errors, here is the environment I was working with:

• Operating system: Windows 10 Pro, 64-bit
• Processor: Intel Core i5–3320M @ 2.60 GHz
• Processor generation: Third-generation Intel Core, Ivy Bridge
• Database: MongoDB Community Server 8.0
• Database tools: MongoDB Compass and the Windows command line
• Initial deployment method: Native Windows installation with a Windows service
• Final approach: MongoDB running inside Docker

My laptop is not a modern machine, but it is still useful for programming, web development, and other development tasks.

I wanted a database setup that was reliable, easy to start and stop, and reusable across multiple projects. I was not looking to build a production database server. I simply wanted a dependable local development environment.

2. The First Problem: MongoDB Could Not Find Its Data Directory

After installing MongoDB, I opened PowerShell and navigated to the installation directory:

cd "D:\Program Files\MongoDB\Server\8.0\bin"

Then I tried to start MongoDB using:

.\mongod.exe

Instead of starting successfully, MongoDB returned an error similar to this:

NonExistentPath:
Data directory \data\db not found.

Create the missing directory or specify another path
using --dbpath or the storage.dbPath setting.

The problem seemed straightforward: MongoDB was looking for a data directory that did not exist.

A database server needs a location where it can store its database files, indexes, and other persistent information. If the configured directory is missing or inaccessible, the server cannot use it.

The solution: Specify the data directory explicitly

I tried starting MongoDB by supplying a specific path:

.\mongod.exe --dbpath "D:\Program Files\MongoDB\Server\8.0\data\db"

This allowed MongoDB to start.

At this point, I thought the main problem was solved. I could start the server manually and connect to it.

However, I did not want to open a terminal and manually run the database server every time I needed it.

I wanted something more convenient.

3. My Next Goal: Manage MongoDB Like XAMPP

I was familiar with the convenience of XAMPP, where I could open a control panel, start the services I needed, stop them when I finished working, and continue with my development.

I wanted a similarly convenient workflow for MongoDB.

Windows provides a Services console, accessible through services.msc, that allows background applications to run as Windows services. MongoDB supports this approach as well.

According to the official MongoDB Windows installation documentation, MongoDB can be configured as a Windows service and managed through the Services console.

I therefore moved on to configuring MongoDB as a service.

Creating the MongoDB configuration

I used a configuration file named mongod.cfg to define the database directory, log file, and network settings.

The configuration looked like this in principle:

storage:
  dbPath: "D:/Program Files/MongoDB/Server/8.0/data"

systemLog:
  destination: file
  path: "D:/Program Files/MongoDB/Server/8.0/log/mongod.log"
  logAppend: true
net:
  port: 27017
  bindIp: 127.0.0.1

These settings tell MongoDB where to keep its data, where to write its logs, which port to use, and to listen only on the local machine.

I then configured the service to use this file.

The service command referenced:

"D:\Program Files\MongoDB\Server\8.0\bin\mongod.exe"
--config "D:\Program Files\MongoDB\Server\8.0\bin\mongod.cfg"
--service

The service was configured to run under the built-in Windows account NT AUTHORITY\NetworkService.

After this setup, MongoDB appeared to work. I could start the service and connect through MongoDB Compass.

But the most frustrating part of the journey was still ahead.

4. The Recurring Problem: Windows System Error 1067

I started using MongoDB for my development work. I created databases, imported collections, and worked with the data.

Then I restarted my laptop.

When I tried starting MongoDB again, Windows displayed this error:

The MongoDB Server (MongoDB) service is starting.

The MongoDB Server (MongoDB) service could not be started.
A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.

At first, I suspected that my configuration was incorrect. Perhaps MongoDB was not finding the database directory, or the service did not have the required permissions.

I checked the service configuration:

sc.exe qc MongoDB

The output showed that the service was pointing to the expected mongod.exe executable and configuration file. It also confirmed that the service ran as NT AUTHORITY\NetworkService.

That meant the basic service registration looked correct.

However, Error 1067 did not explain the underlying reason for the failure. It simply told me that the process had terminated unexpectedly.

I needed to investigate further.

5. The Workaround That Seemed to Fix Everything: Deleting the Data Directory

During troubleshooting, I discovered something that initially made the situation even more confusing.

When MongoDB failed to start, deleting its data directory and starting the server again sometimes made it work.

The process seemed simple:

1. MongoDB failed to start after a restart.
2. I deleted the data directory.
3. I started MongoDB again.
4. MongoDB launched successfully.

Naturally, I started thinking that something was corrupting the database files during a restart.

But there was a serious problem with this workaround.

Deleting the database directory is not a proper repair method.

The directory contains the database’s persistent files. Removing it effectively discards the stored database state. When MongoDB starts with a new, empty directory, it can initialize a fresh database, making the original failure appear to have been fixed.

That explained why the workaround seemed effective: MongoDB was no longer starting with the same existing database files.

It did not prove that the original files were corrupted.

The approach was also unacceptable for real development work. I could not keep deleting my databases whenever I restarted my laptop.

I stopped treating that workaround as a solution and returned to the logs.

6. Investigating the Logs: The Most Important Discovery

I examined MongoDB’s log file:

Get-Content "D:\Program Files\MongoDB\Server\8.0\log\mongod.log" -Tail 50

The log provided much more useful information than the generic Windows service error.

MongoDB successfully performed WiredTiger recovery:

recovery was completed successfully
WiredTiger opened

The database catalog also began initializing. In one of the failing attempts, the log showed 12 catalog records.

Get Moeez Raza’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Then came the critical error:

"msg": "Unhandled exception",
"exceptionString": "0xC000001D"

MongoDB subsequently wrote a minidump diagnostic file and exited.

This changed my understanding of the problem.

The database engine had completed its recovery process before the process crashed. The actual crash was associated with the Windows exception code 0xC000001D, which means an illegal instruction.

An illegal-instruction exception occurs when a program attempts to execute a processor instruction that the CPU cannot execute.

That did not prove every earlier failure had the same cause, but it provided a much stronger lead than my original theory that the database was being corrupted.

7. The CPU Investigation: My Laptop Was an Important Clue

I checked the processor installed in my laptop.

Using PowerShell:

Get-CimInstance Win32_Processor |
    Select-Object Name, Manufacturer, Architecture

Windows reported:

Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz

I also checked the number of cores and logical processors:

Get-CimInstance Win32_Processor |
    Select-Object Name, Description, NumberOfCores,
                  NumberOfLogicalProcessors

The processor had two physical cores and four logical processors.

I was using a third-generation Intel Core processor, based on the Ivy Bridge microarchitecture.

Then I checked MongoDB’s official documentation.

MongoDB’s production notes explain that MongoDB 5.0 and later require a supported CPU microarchitecture. For Intel x86–64 processors, the documented baseline is a Haswell-or-later Core processor, and MongoDB 5.0 also requires AVX support.

My i5–3320M predates that documented baseline.

This gave me a plausible explanation for the illegal-instruction crash: my installed MongoDB build was encountering a CPU compatibility problem.

The evidence was compelling because it connected three observations:

• MongoDB’s log showed an illegal-instruction exception.
• The processor was older than MongoDB’s documented Intel CPU baseline.
• Deleting the database directory did not provide a reliable long-term solution.

I could not conclude that every previous error was caused by the CPU alone, but the evidence indicated that I should stop focusing exclusively on database files and Windows service configuration.

The processor and the particular MongoDB build needed to be considered.

8. I Decided to Try Docker Instead

After spending so much time troubleshooting the native installation, I reconsidered the way I wanted to manage my local databases.

Instead of installing MongoDB directly into Windows and managing it as a Windows service, I decided to run it in a Docker container.

My goal was to separate the database deployment from my normal Windows development environment.

I explored the available MongoDB images and considered three options:

• MongoDB Atlas Local
• MongoDB Community Server
• MongoDB Enterprise Server

For an ordinary local development setup, the Community Server image was the natural starting point. Atlas Local is intended for local development and testing of Atlas-related functionality, while Enterprise Server targets enterprise requirements.

The official Community Server image is available on Docker Hub.

Why this approach appealed to me

Docker allowed me to manage MongoDB as a separate service rather than relying on the native Windows installation.

I could start and stop the container independently of my applications. I could also use the same database server for several projects instead of installing a separate MongoDB instance for each project.

For example, I could create different databases for:

• A FastAPI application
• A Django project
• A PHP application
• Experimental projects and practice

Each application could connect to the appropriate database on the same MongoDB server.

This was much closer to the workflow I wanted.

An important detail: persistent storage

A database container must be configured carefully to preserve its data.

For Docker development, a named volume is a common way to keep database files separate from the container’s writable layer. A volume can survive container replacement, provided it is not explicitly deleted.

Restarting a computer is different from removing a container or deleting a volume. These distinctions matter when configuring persistent database storage.

I wanted a setup in which restarting my laptop would not force me to recreate my databases.

9. The Test That Finally Gave Me Confidence

After setting up MongoDB in Docker, I tested it with actual data rather than stopping after a successful startup.

I added database data and restarted my laptop.

After the restart, I started or accessed the Docker-based MongoDB service and checked whether the data was still available.

This time, everything was working as expected.

The database was available, the data remained accessible, and I could continue developing without deleting the database directory.

That was the result I had been trying to achieve from the beginning.

It was an important improvement to my workflow because a database that starts successfully once is not enough. A useful development environment must also behave reliably across normal restarts.

One technical point is worth keeping in mind: Docker does not give the host a newer physical CPU or automatically make unsupported processor instructions available. Because my container worked, the exact image version and runtime environment matter when explaining why it succeeded. The native Windows logs strongly indicated an instruction-compatibility problem, but I would need to compare the exact container image, MongoDB version, and runtime logs before claiming that the CPU issue was definitively resolved by Docker itself.

Nevertheless, the practical result was encouraging: my Docker-based setup passed the restart-and-data-persistence test that had repeatedly failed with the native installation.

10. What I Learned From This Experience

Looking back, the biggest lesson was that the first visible error is not always the root cause.

A missing directory is not necessarily the whole problem

The initial NonExistentPath error was real, and specifying a data directory solved that particular startup issue.

But fixing the directory did not resolve the later crash.

Windows Error 1067 is a symptom, not a diagnosis

The message only indicated that the service process had terminated. Looking at the MongoDB logs revealed the more important exception.

Whenever a service fails, the application’s own logs can be far more useful than the generic Windows error.

Do not delete database files to make a server start

Deleting a data directory can make a server start with a clean database. It does not establish that the original database was corrupt or repairable.

Before changing database files, make a backup and understand what the log indicates.

Check hardware compatibility early

Developers often focus on software configuration and forget about the machine itself.

In my case, the processor model became a significant clue after I found the illegal-instruction exception.

Checking the official supported-platform documentation can save considerable troubleshooting time.

Containers make development environments easier to manage

Docker provides a repeatable way to run services independently of the application code and the host’s native service configuration.

It also helps developers use consistent database versions across different projects.

But containers are not magic. They still depend on the host’s hardware, and persistent volumes and backups still need to be managed correctly.

11. How I Would Approach the Same Problem Today

If I encountered this problem again, I would follow a more systematic process:

1. Read the first startup error. Identify missing directories, invalid configuration, and permission problems.
2. Verify the configuration. Check the configured dbPath, log path, listening port, and service command.
3. Inspect the application log. Look for the earliest fatal error, not only the final service failure.
4. Check the hardware and software requirements. Confirm that the database version supports the CPU architecture and operating system.
5. Protect the existing data. Stop deleting database directories as a troubleshooting shortcut; make backups before attempting recovery.
6. Test a reproducible deployment. Use Docker or another suitable deployment method, pin the image version, and configure persistent storage.
7. Test across restarts. Create sample data, restart the service, and then restart the computer to verify that both the service and the data persist.

These steps would have helped me move from trial-and-error troubleshooting to a more evidence-based diagnosis.

Conclusion: The Best Setup Is the One That Works Reliably

My experience with MongoDB started with a missing data directory, continued through Windows service configuration and repeated Error 1067 failures, and eventually led me to investigate an illegal-instruction crash.

For a while, deleting the data directory seemed like the only way to get the server running. But it was destructive, and it did not address the underlying problem.

Examining the logs and checking the CPU specification changed my direction. I decided to move my development database into Docker, and the container-based setup successfully preserved my test data across a laptop restart.

I still need to distinguish the observed success from a fully confirmed root-cause diagnosis, but the result gave me a more convenient development workflow.

The takeaway for other developers is simple: don’t keep repeating a workaround when the evidence suggests a deeper compatibility problem. Check the logs, protect your data, verify hardware requirements, and choose a deployment method that you can reproduce and maintain.

For me, this was more than a MongoDB troubleshooting exercise. It was a reminder that reliable development depends not just on writing code, but also on understanding the environment in which that code runs.