SQL Server 2017 crashes when backing up because filepath is wrong
I was able to reproduce this.

On 2016, if I put an invalid path like that, I get this message:


  Cannot open backup device 'D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak'. Operating system error 3(The system cannot find the path specified.)


On 2017 CU 13 (14.0.3048.4), it results in the service crashing.  You've already mentioned that in the latest hotfix (14.0.3049.1), the service doesn't crash, but the session is killed.

I've confirmed the same exact behavior applies to RESTORE DATABASE as well - passing a path like "D:Backups" (with a missing backslash) or "D::\Backups" (extra colon) crashes the SQL Server instance (thanks Michael K Campbell for bringing this up).

If I put a "valid" path that doesn't exist, I get the correct behavior ("cannot find the path specified") in 2017.

This is a bug - in both CU 13 and the hotfix build.  Passing incorrect parameters to the BACKUP or RESTORE commands shouldn't crash the service or kill your session.  You can report it on the feedback site.

Note: the service-crashing version of this bug can be reproduced in a public preview version of SQL Server 2019 (CTP2.2 - thanks to Denis Rubashkin for pointing this out)



Looking at this in a debugger, it seems that path validation code is simply broken. It ends up causing a stack overflow by recursively calling into sqlmin!CheckFileStreamReserved after the normal (and quite extensive) checks on the supplied path fail to make sense of it. The stack overflow brings down the service on build 3048. The same thing happens on 3049 except a sequence of access violations while attempting to handle the stack overflow instead breaks the connection rather than stopping the whole server.



A fix for this bug was released in SQL Server 2017 CU 15:

FIX: SQL Server 2017 crashes because of stack overflow when you try to back up database master to disk

The issue is also resolved in SQL Server 2019 CTP 3.0.