none
SQLServer 2017 Developer edition engine service stopped working after the update kb293803 RRS feed

Answers

  • My advice would be that you turn the UTF-8 setting, although I don't know what other dependency you might have with it. But apparently, SQL Server does not currently play well with it. Which I think it should, at least the day the checkbox is not beta any more.

    I looked your install files and they are binary the same as the install files as I have on my instance running SQL 2017 CU9 + GDR. I just wanted to make sure that there is nothing funny going there.

    I will bring up this incident with my contacts at Microsoft. Possibly this will result in a feedback item later on. In that case, I will share the link.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Sunday, August 26, 2018 5:01 PM

All replies

  • There were issues with the GDR for some versions of SQL 2016, but I have not heard of any issues for SQL 2017.

    Can you be more specific with "stopped working" means. Did you try to start it manually? If that fails, have you checked the SQL Server error for messages? Windows event log?


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Saturday, August 25, 2018 12:01 PM
  • There were issues with the GDR for some versions of SQL 2016, but I have not heard of any issues for SQL 2017.

    Can you be more specific with "stopped working" means. Did you try to start it manually? If that fails, have you checked the SQL Server error for messages? Windows event log?


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se


    i was working with it windows update downloaded the patch and installed it and needed restart so i restarted my PC but the service for the engine didn't start automatically as usual so i tried to start it manually from Services and the Configuration Manager

    i have this errors

    Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 200, state 7, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.

    and

    Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.

    and reinstalling it makes it work until i restart and the same thing happen again

    Saturday, August 25, 2018 1:16 PM
  • That's what they call bad news.

    You are probably for an operation to rebuild master. Hopefully, you user databases are intact. Are you lucky enough to have a backup of your master database?

    Before we go there, could you get all ERRORLOG files in C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Log and upload them somewhere? (OneDrive, Dropbox). We should se more about this error in one of them. (Interesting enough, there is no error with message_id 200 in sysmessages.)


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Saturday, August 25, 2018 6:11 PM
  • That's what they call bad news.

    You are probably for an operation to rebuild master. Hopefully, you user databases are intact. Are you lucky enough to have a backup of your master database?

    Before we go there, could you get all ERRORLOG files in C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Log and upload them somewhere? (OneDrive, Dropbox). We should se more about this error in one of them. (Interesting enough, there is no error with message_id 200 in sysmessages.)


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    sure here is everything in the folder https://1drv.ms/u/s!AgTa5KowAj5Vgr8szpBLM44vals3Kg
    Saturday, August 25, 2018 6:50 PM
  • Thanks for the files! I found what is going wrong, and it's leaving me perplexed. But maybe there is a simple answer. Can you please go into the registry and tell me the value of this parameter:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\OEMCP


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Saturday, August 25, 2018 8:56 PM
  • Thanks for the files! I found what is going wrong, and it's leaving me perplexed. But maybe there is a simple answer. Can you please go into the registry and tell me the value of this parameter:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\OEMCP


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se


    Saturday, August 25, 2018 10:23 PM
  • That confirmed my suspicion. That sort of explains why you get the error message that prevents SQL Server to start. I say sort of, because I am not enitrely happy with SQL Server.

    However, your machine is in an unexpected state with regards to code pages. All your code pages, ACP, OEMCP and MACCP is 65001, that is, UTF-8. Do you have any idea how this happened?

    If you are not acquainted with code pages, I will try to explain. Many Windows programs work with Unicode, and Unicode in Windows means the encoding UTF-16LE. But there are also many programs that work with character sets, known as code pages, that are tailored for a certain locale. True Windows program uses the ANSI code page, which is ACP. Programs that live in the command-line space, often use the OEM code page. All these code pages have the first 127 code points defined in the same way, the ASCII character set. Then remaining code points are for characters not (commonly) used in English, and different code pages support different languages.
    UTF-8 is a Unicode encoding, but as far as Windows is concerned, it is another code page. Having UTF-8 as the ANSI and OEM code pages is nothing I have heard of, but I am not a Windows expert. Out of curiousity, if you open the Region applet in the Control Panel, and go to the Administrative tab, what do you see? Can you provide a screen shot?
    Why does this prevents SQL Server from starting? The upgrade script mentioned in the error message performs a number of active, one of the is loading a "collector package" (that I don't know what it is) with BULK INSERT which objects with  The code page 65001 is not supported by the server. This is itself a bit of a mystery. It used to be that BULK INSERT actively blocked this code page, because it could not handle UTF-8 properly, but this was fixed with SQL 2014 SP2. So I don't understand why this error comes up here, but may be there is some special code path being hit when running install scripts.

    I don't really have any advice what you should do at this point. Don't go and change the registry values directly. I tried that on one my virtual machines, and after a reboot Windows went into automatic recovery! Thankfully, I had taken a snapshot that I could revert to.

    Could you also upload the contents in the folder C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Install to your OneDrive? I like to compare it with my own installations to see if there any differences.

    Do you have any other Windows computers around? In that case, you could check their code-page settings and system locales, just to see if that can give you an idea why your machine looks like it does.

    Sunday, August 26, 2018 9:55 AM
  • I activated the beta utf-8 support



    i have a labtop with that option disabled and sqlserver works on it after the update just fine

    and here is the install log folder

    https://1drv.ms/u/s!AgTa5KowAj5VgsFOWnQcAIcqncMlXQ
    Sunday, August 26, 2018 1:14 PM
  • My advice would be that you turn the UTF-8 setting, although I don't know what other dependency you might have with it. But apparently, SQL Server does not currently play well with it. Which I think it should, at least the day the checkbox is not beta any more.

    I looked your install files and they are binary the same as the install files as I have on my instance running SQL 2017 CU9 + GDR. I just wanted to make sure that there is nothing funny going there.

    I will bring up this incident with my contacts at Microsoft. Possibly this will result in a feedback item later on. In that case, I will share the link.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Sunday, August 26, 2018 5:01 PM
  • i duel boot with linux and it uses utf-8 by default so i activated the option so i don't have to edit the files i works on encode manually to utf-8 i will turn the utf-8 support on windows back of and see what happens
    Sunday, August 26, 2018 7:11 PM
  • You should still be able to work with UTF-8 files without this setting. The only difference is that you when create a new file with, say, Notepad, you will need to remember to select UTF-8 when you save the file when you don't have this setting checked.

    Please let us know how it works out!


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Sunday, August 26, 2018 7:17 PM
  • that's what i meant by "manually" it's just annoying, anyway

    it seems like you said the upgrade codes can't handle UTF-8
    i disabled the UTF-8 option restarted the PC and the SQLServer work again automatically activated the UTF-8 support again restarted and now it still works

    thanks for taking the time to help me out figuring what's is wrong with it.
    Sunday, August 26, 2018 7:48 PM
  • Glad to hear that it worked out! Yes, I would expect SQL Server to run once in this UTF-8 world, once you've past this hurdle. Just remember to turn it off next time you install an SQL Server update.   ...or keep it set, to see if they have fixed this issue. Just be prepared to turn if off, if they have not.

    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Sunday, August 26, 2018 7:53 PM
  • i will keep it in mind
    Sunday, August 26, 2018 8:10 PM
  • I've made some tests myself and reproed the problem. In fact, I did not even have to try an upgrade, because BULK INSERT always fails with this error when you have enabled the UTF-8 support for the system locale.

    I have created a Feedback item for this:

    https://feedback.azure.com/forums/908035-sql-server/suggestions/35245150-bulk-insert-does-not-work-utf-8-support-enabled-fo


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    Wednesday, August 29, 2018 7:58 PM
  • I've made some tests myself and reproed the problem. In fact, I did not even have to try an upgrade, because BULK INSERT always fails with this error when you have enabled the UTF-8 support for the system locale.

    I have created a Feedback item for this:

    https://feedback.azure.com/forums/908035-sql-server/suggestions/35245150-bulk-insert-does-not-work-utf-8-support-enabled-fo

    I'm sure Erland has already seen this due to my updating that feedback item, but just so that Ahmed also sees it: the problem exists with both BULK INSERT and OPENROWSET(BULK...), but BCP works just fine. I realize that doesn't help with this immediate issue of doing upgrades since BULK INSERT is in the code (in 2 places), but just FYI. For complete details of what I tested and found, please see the feedback item that Erland created and linked in the quoted section immediately above.

    Take care, Solomon...

    Thursday, January 17, 2019 7:07 AM