You are comparing apples to motorcycles.
Windows 95 traces its lineage back through Windows 3.x all the way to Windows 1.x and MS-DOS/PC-DOS, themselves inspired by CP/M. It was conceived and designed as a single-user, cooperatively multitasking environment in which applications have a large degree of freedom in what to do. Windows 95 moved towards a preemptive multitasking design, but still had significant cooperative elements built-in.
The fact that it was intended as a consumer OS replacement for the combination of MS-DOS and Windows 3.1/3.11, and was to work (not necessarily provide a great user experience, but boot and allow starting applications) on as low end a system as any 386DX with 4 MB RAM and around 50 MB of hard disk space, also put huge limitations on what Microsoft could do. Not least of this is its ability to use old MS-DOS device drivers to allow interoperability with hardware which did not have native Windows 95 drivers.
So while Windows 95 provided a hugely revamped UI compared to Windows 3.x, many technical improvements and paved the way for more advanced features, a lot of it had compatibility restraints based on choices, and to support limitations in hardware, dating back over a decade. (The 386 itself was introduced in 1985.)
Now compare this to modern versions of Windows, which don't trace their lineage back to MS-DOS at all. Rather, modern versions of Windows are based on Windows NT which was basically a complete redesign, originally dubbed NT OS/2 and named Windows NT prior to release.
Windows NT was basically designed and written from the beginning with such things as user isolation (multiuser support), process isolation, kernel/userspace isolation (*), and no regard for driver compatibility with MS-DOS.
For a contemporary version, Windows NT 3.51 was released three months before Windows 95, and required at a minimum a 386 at 25 MHz, 12 MB RAM, and 90 MB hard disk space. That's quite a step up from the requirements of Windows 95; three times the RAM, twice the disk space, and quite possibly a faster CPU (the 386 came in versions clocked at 12-40 MHz over its product lifetime), and again, that's just to boot the operating system.
Keep in mind that at the time, a 486 with 8-12 MB RAM and 500 MB hard disk was a reasonably high end system. Compare Multimedia PC level 2 (1993) and level 3 (1996), only the latter of which went beyond a minimum of 4 MB RAM. Even a MPC Level 3 PC in 1996 wouldn't meet the hardware requirements of the 1995 Windows NT 3.51, as MPC 3 only required 8 MB RAM.
From a stability point of view, even Windows NT 3.51 was vastly better than Windows 95 could ever hope to be. It achieved this, however, by sacrificing a lot of things that home users would care about; the ability to run well on at the time reasonably affordable hardware, the ability to run DOS software that accessed hardware directly (as far as I know, while basic MS-DOS application compatibility was provided, there was no way other than dual-boot to run most DOS games on a Windows NT system), plug-and-play, and the ability to use hardware that lacked dedicated Windows NT drivers.
And that's what Microsoft has been building on for the last about two decades to create what we now know as Windows 10, by way of Windows NT 4.0, Windows 2000, XP, Vista, 7 and 8. (The DOS/Windows lineage ended with Windows ME.)
As another-dave said in another answer, process isolation (which is a cornerstone for, but on its own not sufficient to ensure, system stability) isn't a bolt-on; it pretty much needs to be designed in from the beginning as, if it isn't there, programmers (especially back in the day, when squeezing every bit of performance out of a system was basically a requirement) will take shortcuts which will break if you add such isolation later on. (Compare all the trouble Apple had adding even basic protections to classic Mac OS; they, too, ended up doing a complete redesign of the OS that, among other things, added such protections.) Windows 95 didn't have it, nor was the desire from Microsoft to do the work needed to add it there; Windows NT did have such isolation (as well as paid the cost for having it). So even though Windows NT was far from uncrashable, this difference in the level of process isolation provided by the operating system shows in their stability when compared to each other, even when comparing contemporary versions.
*) The idea behind kernel/userspace isolation (usually referred to as "ring 0" and "ring 3" respectively in an Intel environment) is that while the operating system kernel has full access to the entire system (it needs to, in order to do its job properly; a possible exception could perhaps be argued for a true microkernel design, but even there, some part of the operating system needs to perform the lowest-level operations; there's just less of it), normal applications generally don't need to have that level of access. In a multitasking environment, for just any application to be able to write to just any memory location, or access any hardware device directly, and so on, comes with the completely unnecessary risk of doing harm to the operating system and/or other running applications.
This isn't anywhere near as much of a problem in a single-tasking environment such as MS-DOS, where the running application is basically assumed to be in complete control of the computer anyway.
Usually, the only code (other than the operating system kernel proper) that actually needs to have such a level of access in a multitasking environment is hardware drivers. With good design, even those can usually be restricted only to the portions of the system they actually need to work with, though that does increase complexity further, and absent separate controls, a driver can always claim to need more than it strictly speaking would need.
Windows 95 did have rudimentary kernel/userspace and process/process separation, but it was pretty much trivial to bypass if you wanted to, and drivers (even old DOS drivers) basically bypassed it by design. Windows NT fully enforced such separation right from the beginning. The latter makes it much easier to isolate a fault to a single process, thereby greatly reducing the risk of an errant userspace process causing damage that cannot be known to be restricted only to that process.
Even with Windows NT, back then as well as today, if something went/goes wrong in kernel mode, it would generally cause the OS to crash. It was just a lot harder to, in software, cause something to go sufficiently wrong in kernel mode in Windows NT than in Windows 95, and therefore, it was correspondingly harder to cause the entire operating system to crash. Not impossible, just harder.