Ошибка 3414 не запускается служба sql server

During the startup of SQL Server, a process called database recovery occurs for every database residing on the instance which includes system databases as well. In a scenario where for multiple reasons the recovery process fails, the SQL Server would report an error 3414 in the ERRORLOG and the Windows Application Event Log. The error indicates would look like this:

“An error occurred during recovery, preventing the database ‘YourDB’ (database ID 11) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support)”

A similar error is shown below from the Services Manager when starting SQL Server fails to start with error code 3414.

As mentioned earlier, there are several reasons that could be the root cause for this error. Until the error is resolved you will be restricted in working with the database. In order to resolve issue, you need to examine the error preceding this error in the ERRORLOG or Event Log to determine the underlying issue. In majority of cases, the database is set to ‘Suspect’ mode and may incur additional errors on further usage. The Error message 926 usually appears on your screen when you try to access the SQL database marked as ‘Suspect’.

One typical example of error 3414 is when recovery of a database fails and encounters a checksum error while attempting to read a block in the transaction log file. For such an example, you would see similar errors in your SQL error log below:

2018-08-20 14:30:37.68 spid15s Error: 824, Severity: 24, State: 4. 2018-08-20 14:30:37.68 spid15s SQL Server detected a logical consistency-based I/O error: (bad checksum). It occurred during a read of page (0:-1) in database ID 14 at offset 0x0000000000b900 in file ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2K14MSSQLDATAmydata_log.LDF’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online. 2018-08-20 14:30:37.81 spid15s Error: 3414, Severity: 21, State: 1. 2018-08-20 14:30:37.81 spid15s An error occurred during recovery, preventing the database ‘mydata’ (database ID 14) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support

How to Resolve the SQL Server Error 3414?

There are 3 ways of rectifying this error code 3414 when the database recovery fails. The chart below shows what options are available to help resolve this issue.

Method 1: Restore from Good Known Backup

The most recommended option is restoring from a good known backup. The database curator needs to utilize the most current backup file for restoring the suspect database. To learn more about restoring a backup for a suspect SQL database, click this link.

Method 2: Manual Copy of Data / DBCC CHECKDB REPAIR

The next method of a resolution would be executing DBCC CHECKDB command. This manual intervention will be best to retrieve back your database in an online and accessible mode. However, due to the recovery failure, consistency of transactions is not guaranteed after a repair. It is almost impossible to track the transactions, which have been rolled back or forward but, were not completed. The commands below would attempt to repair the suspect database using the DBCC CHECKDB feature:

This set of commands would put the database in ethe mergency state.

EXEC sp_resetstatus 'db_name';
ALTER DATABASE db_name SET EMERGENCY

Perform an integrity and consistency check on the database.

DBCC CHECKDB ('database_name')

The check would recommend the minimal repair level. Set database to single user to allow repair.

ALTER DATABASE database_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Run the repair command as shown below

DBCC CHECKDB ('database_name', REPAIR_ALLOW_DATA_LOSS)

Once the repair is complete, set database back to multi-user to allow connections.

ALTER DATABASE database_name SET MULTI_USER

In some cases, the steps provided using DBCC CHECKDB fails to repair and recover the suspect database. You can attempt to COPY OUT as much data as possible from the suspect database. In order to do that, you would need to put the database back into EMERGENCY mode. This would allow you to access the content of the database. At this point try to copy as much as possible out of the database into a new database. Use the following command below to put the database into EMERGENCY:

EXEC sp_resetstatus 'db_name';
ALTER DATABASE db_name SET EMERGENCY

Methods 3: Repair Using SQL Recovery Software

Finally, if you find yourself in the worst-case scenario where all the above solutions did not work out, then the Stellar Repair for MS SQL software can help you perform a SQL error 3414 repairs. The software has dedicated and easy-to-use mechanism to effectively repair corrupt SQL databases and safely recover all the database objects like tables, views, indexes, keys, constraints, etc. stored in the database. The renowned tool enables you to efficiently resolve error 3414 which saves you from the risk of looming data loss. The software supports all the latest SQL Server versions, from SQL Server 2019, 2017, 2016 to 7.0.

About The Author

Priyanka

Priyanka is a technology expert working for key technology domains that revolve around Data Recovery and related software. She got expertise on SQL Database. Loves to write on different technology and data recovery subjects on regular basis. Technology freak who always found exploring neo-tech subjects, when not writing, research is something that keeps her going in life.

As we all know, Microsoft released MS SQL Server 29 years ago i.e. SQL Server 1.0 and for ages, it has reached many milestones with its ease of use and security. It has grabbed its own space in online markets with lightning speed over the years. The latest version was released in 2017 i.e. SQL Server 2017 which also supports Linux platforms as well such as Red Hat Enterprise Linux, Ubuntu, SUSE Linux Enterprise & Docker Engine.

MS SQL Server is a management system for storing and extracting data from the connected application. Though the most widely used secure and safe database server, it is also prone to unexpected errors. One such error is “SQL Error 3414” –

SYMPTOMS of the Error 3414:

The error is caused when the SQL Server service does not start during login or startup of database recovery. Hence, the database fails to retrieve causing MSSQL error code 3414.

The extended form of the error written to ERRORLOG or Windows Application Event Log with EvenetID-3414 with SQL Server is as follows:

“Error: 3414, Severity: 21, State: 1.
An error occurred during recovery, preventing the database ‘mydb’ (database ID 13) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support)”

Usually, an error that precedes Error 3414 in the ERRORLOG or Event Log is the reason for SQL database recovery failure.

Also, the status of the database is set to SUSPECT. The SUSPECT status is reflected in SQL Server Management Studio and sys.databases.state_desc. If you try to operate the database in this state you might encounter “SQL suspect database error 926” as follows:

Understand the Primary Cause of the Error 3414

The basic cause of the occurrence of error 3414 is due to the same SPID value in the server log file with the failure in the recovery of the database file. Go through the following checksum error that occurred during the time of the “read page” operation in the database to roll forward a transaction.

“2010-03-31 17:33:13.00 spid15s Error: 824, Severity: 24, State: 4.
2010-03-31 17:33:13.00 spid15s SQL Server detected a logical consistency-based I/O error: (bad checksum). It occurred during a read of page (0:-1) in database ID 13 at offset 0x0000000000b800 in file ‘C:Program FilesMicrosoft SQL ServerMSSQL10.SQL2008MSSQLDATAmydb_log.LDF’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
2010-03-31 17:33:13.16 spid15s Error: 3414, Severity: 21, State: 1.
2010-03-31 17:33:13.16 spid15s An error occurred during recovery, preventing the database ‘mydb’ (database ID 13) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support”

Resolution to Fix “Error Code 3414” in SQL Server?

The best possible solution to resolve the SQL Server error 3414 is to restore the database from a backup (if available) using SQL Server Management Studio. It is a good practice to take timely backups for handling unexpected disastrous situations. But, there are times when it is not possible to recover from a backup of the database or incomplete data is restored from your available backup. Here are the following methods to fix the error:

Method 1: Use DBCC CHECDB for emergency repair

Executing DBCC CHECDB should be your first step to get back the database to running state.

DBCC CHECKDB
[ ( database_name | database_id | 0
[ , NOINDEX
| , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
) ]
[ WITH
{
[ ALL_ERRORMSGS ]
[ , EXTENDED_LOGICAL_CHECKS ]
[ , NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , { PHYSICAL_ONLY | DATA_PURITY } ]
[ , MAXDOP = number_of_processors ]
}
]
]

However, it the best method but transactional consistency is not guaranteed since recovery failed. There are no ways to find out which transactions were rolled back or rolled forward and not allowed due to recovery failure.

Method 2: Copy Entire (healthy or recoverable data) Database to another Database

If the first workaround method fails to work, then you must try to copy all the possible data that is in the healthy or recoverable state to another database. To do this, set the database in emergency mode with the help of the given command:

ALTER DATABASE <dbname> SET EMERGENCY

After setting emergency mode, you can try to copy or move all the data to another database.

Resolve with Automated Method – SQL Database Recovery

In case the above-mentioned methods fail to fix and recover the database, then we recommend you immediately choose SQL Database Recovery software. This SQL Recovery is the most trustworthy software that serves the purpose of resolving SQL Server error code 3414. The software is specially designed for the recovery of corrupt and inaccessible SQL database files of any SQL server version.

Conclusion

In this blog, we have completely analyzed one of the common SQL Server errors which occur during the database recovery. Along with symptoms, primary cause, three potential manual solutions, a complete SQL Database Recovery software for quick and fine recovery of data from corrupted SQL Server database file is proposed in the end.

SQL Server Error 3414: Windows could not start the SQL Server on Local Computer

“I was performing manipulation commands on SQL Server Database, but suddenly my database got crashed due to some accidental changes done in my database. I tried to recover it from DBCC CHECKDB but failed to recover it. Also tried restoring it from backup and got SQL Server Error 3414, Severity: 21, State: 1″Now, I am stuck and worried about my data stored in my SQL Server database. Please suggest me a way using which I can fix this error and recover my database.”

SQL server is a relational database management system (RDMS). It is one of the innovative technologies that has changed the way of handling and work with the data. Still, there are many users who are facing issue while working with Microsoft SQL Server.

Therefore, in this blog, we are going to discuss the most common error faced by MS SQL users that is ‘SQL Server service not starting error 3414’. We will also introduce a reliable and efficient way to resolve this error.

Instant Solution: Use SQL Database Recovery Tool if are unable to troubleshoot SQL error 3414 using DBCC CHECKDB command. This application will help the user to repair corrupt SQL database files MDF and NDF without backup.

Download Now Purchase Now

SQL Server Error 3414 – Know About it

SQL error 3414 occurs when the database fails to recover. The status of the Database in SUSPECT Mode after the occurrence of the error. The effect of this error is reflected in SSMS and in the column of sys.databases.state_desc. If user try to connect the database in this error , then it will result in SQL database suspect error 926.

When a line in the server log file has the same value of SPID, SQL Server error 3414 is encountered. For example, sometimes the recovery failure is due to checksum error when trying to read a log block to roll forward a transaction.

It is necessary to know the root cause of the error. One can examine the root cause of this error by checking the ERRORLOG. This helps the user to resolve the issues by applying the appropriate method. Once the user is aware of the cause that leads to ‘Windows could not start the SQL server on Local Computer error code 3414’ then he/she can adopt healthy measures to prevent the error Accordingly.

Troubleshoot Microsoft SQL Error 3414

The user can implement different methods to resolve ‘SQL Server Service not starting error 3414’. However, restoring from a good backup is the most suitable option to resolve this issue. If the user is not able to recover from a backup then he/she can adopt the following methods given below:

• Using Emergency Repair method provided by DBCC CHECKDB
• Try to copy data from one database to another database
• Use automated solution – SQL Recovery

#Method 1: Use Emergency Repair provided by DBCC CHECDB

Executing DBCC CHECKDB command should be the first priority of the user. This method will help the users to get the database in online and accessible mode. However, due to the recovery failure, the consistency of the transactions is not guaranteed. Therefore, it is nearly impossible to track the transactions, that should be rolled back or rolled forward.

Now, you have to use DBCC statements with REPAIR_ALLOW_DATA_LOSS option. This option will eliminate all the damaged and inconsistent data and will result in the physically consistent database. To run the consistency check, run the command given below:

ALTER DATABASE database_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DBCC CHECKDB(database_name,REPAIR_ALLOW_DATA_LOSS)
GO

If you are not able to fix the SQL Server error 3414 using the above method then switch to the other methods given below.

#Method 2: Copy or Move Data to Another Database

Try to copy the data into another database, this will help you to get access to the database. Before doing this task, you have to put the database in emergency mode by following the below-mentioned command.

ALTER DATABASE database_name SET EMERGENCY

Switch to Instant and Reliable Solution

The users may face data loss issue with the above methods explained. Moreover, a person having good technical knowledge can implement the above steps in an accurate way. To resolve SQL Server Service not starting error 3414 in a convenient way, it is recommended to use SQL Recovery Application. This utility will help the user to repair corrupt SQL Server database and export that in a healthy state. The user-friendly interface of the software makes it easy for the users to work with it and make database in accessible mode. Moreover, there is no risk of data loss associated with the software.

Download Now

Conclusion

Sometimes the SQL server database becomes inaccessible when you try to connect it. The reasons could be many. The blog covers the solution to the problem ‘Windows could not start the SQL server on Local Computer error code 3414’. The blog discusses the possible reasons for getting SQL Server error 3414. To resolve this issue, it covers the step by step manual procedure. There could be the possibility that the manual method fails to recover the database in SUSPECT mode. So, here we also discuss an automated solution to fix ‘Error 3414, Severity: 21, State: 1’. This will help the user to troubleshoot the SQL Server Service not starting error 3414 and repair database in a hassle-free way.

SQL Server goes into whole recovery phase on each time login and sometimes there are complaints by the users stating crash down of the server with an error like this.

It can occur even while applying any functions or manipulations and when the SQL Server service is not started with the login on the SQL Server. Here, as we can see in the error message, the recovery failure occurred due to the service-specific error code 3414. In the Event Log, the reason behind this failure can be detected as it depends on the preceding error logs with log files having similar SPID value.

When user tries to roll forward a transaction log with read page operation on the database, the checksum error appears like this:

“2010-03-31 17:33:13.00 spid15s Error: 824, Severity: 24, State: 4.
2010-03-31 17:33:13.00 spid15s SQL Server detected a logical consistency-based I/O error: (bad checksum). It occurred during a read of page (0:-1) in database ID 13 at offset 0x0000000000b800 in file ‘C:Program FilesMicrosoft SQL ServerMSSQL10.SQL2008MSSQLDATAmydb_log.LDF’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
2010-03-31 17:33:13.16 spid15s Error: 3414, Severity: 21, State: 1.
2010-03-31 17:33:13.16 spid15s An error occurred during recovery, preventing the database ‘mydb’ (database ID 13) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support”

With the failure of database recovery and onset of this error, the database goes into SUSPECT mode which is visible against the server database name in the SQL Server Management Studio.

If any user tries to use the database in this SUSPECT mode, he has to encounter the progressive error stating –

“Msg 926, Level 14, State 1, Line 1
Database ‘mydb’ cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information”

So, there is a need to fix this error code 3414 issue to get back the normal database functioning once again. As we know handling the SQL Server, its features and functions is a bit complex task. So, there is a need of technical knowledge for performing manual solutions which might include running SQL Server queries to repair or restore the SUSPECT database in SQL Server; you can also restore SQL Database with a different name.

As recommended by Microsoft itself, we are explaining some of the workable manual methods for fixing or resolving this SQL Server error. Keep following carefully these methods and use them accordingly.

1st Method: Go for Restoring SQL Data through Recent Database Backup

If SQL Server user is in good practice of taking regular backups of their SQL database file and need to access it urgently. Then, restoring data from backup is a nice and easy choice. Perform these easy steps in order to restore your database from backup file.

1. Launch the Microsoft SQL Server Management Studio as an administrator.
2. Go to Object Explorer panel on the left, make connection to SQL Server Database Engine, select it and expand.
3. Now select Databases option and right-click on it. Select Restore Database option from the list.
4. Next, on the General page, under Source section, choose the Database option and add the recent database backup file from the list.
5. The restore process will get started and complete based on the database size.
6. Restart the SQL Server and check for the error code oncoming again.

For users who don’t have any backup file for the SQL database, we have other manual solutions as well.

2nd Method: Perform Emergency Repair Solution via DBCC CHECKDB

SQL Server provides its users certain SQL Query and commands to check upon the integrity of the SQL Database. DBCC CHECKDB command is helpful in checking the database in terms of accessibility and fixing related issues. Databases should be put in emergency mode as transaction consistency (no tracking of transaction roll back and forward) is not possible with DBCC command alone.

To put the databases in emergency mode, execute this command in New Query in SQL Server Management Studio run as administrator on your SQL system.

EXEC sp_resetstatus ‘db_name’;
ALTER DATABASE db_name SET EMERGENCY

Provide SQL Server database name at the required locations in the commands.

Perform integrity check on the SQL Server database using the following command.

DBCC CHECKDB (‘database_name’)

After checking the consistency of the database, the minimal repair recommendation would display. For that, to allow repair, set the database to single user executing this command.

ALTER DATABASE database_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Run the DBCC repair command as follows with introduction of “Repair Allow Data Loss” feature.

DBCC CHECKDB (‘database_name’, REPAIR_ALLOW_DATA_LOSS)
After this repair, users can set the database to multi-user for connections using this command.
ALTER DATABASE database_name SET MULTI_USER
And if the steps failed to repair the SUSPECT database, try copying out data from the database to a new database after putting it back in emergency mode. It will let you access the database content.
EXEC sp_resetstatus ‘db_name’;
ALTER DATABASE db_name SET EMERGENCY

Exit the Microsoft SQL Server Management Studio. Now, restart the server and check if the issue is resolved.

What to do if this method did not work?

It is possible that simply executing DBCC CHECKDB command in emergency mode does not fix the error. You can use COPY OUT command to copy the whole database to a new database but needs to put the databases in the emergency mode using this command as used earlier.

EXEC sp_resetstatus ‘db_name’;
ALTER DATABASE db_name SET EMERGENCY

Note: SQL administrators can follow the online troubleshooting solutions provided in the Event Error Log itself.

How manual solutions are not completely reliable?

Restoring database manually from backup file does not ensure the complete backup of SQL database objects. It might include data loss or modification during the whole process. Also DBCC CHECKDB command is not helpful due to issues of transaction log files tracking as some or other manual errors can be expected even in the Emergency mode. All these tricks require good amount of time and efforts with some technical knowledge. So, limitations might hold back users and lead them to look for a better alternative.

Alternative Option – Third Party tool

If you lack trust in manual solutions or already tried the above tricks but not succeeded, we offer you the best SQL Server recovery tool in the market which includes the most advanced programming and algorithms to tackle all kinds of SQL Server errors including SQL database corruptions and resolve it within few minutes. It only requires the database file for the repair process and supports all SQL Server versions widely. Go on this utility website and checkout all the features in detail. You can download the trial version for free and get the experience of efficient Recovery anytime.

Download Now

Conclusion

We have concluded that SQL Server errors can be tackled manually (as some methods like restore from backup, DBCC CHECKDB repair in emergency mode are explained) but from these tricks, complete reliability cannot be assured. Third-party utility which could be your savior in dealing with complex SQL Server error codes.

  

zak555

29.06.16 — 11:39

  

piter3

1 — 29.06.16 — 11:41

  

vde69

2 — 29.06.16 — 11:41

  

mistеr

3 — 29.06.16 — 11:42

Ждите, после включения электричества запустится.

  

mistеr

4 — 29.06.16 — 11:48

А если серьезно, при восстановлении БД что-то пошло не так. Настоящая причина где-то рядом в логах, ищи.

  

mistеr

5 — 29.06.16 — 11:49

  

jsmith

6 — 29.06.16 — 12:11

В (1) пишут скопировать файлы model с другого экз. СУБД.

  

vde69

7 — 29.06.16 — 12:14

(6) если бекапы есть и уперлись в непонятки — проще снести скуль и поставить заново, а потом восстановить бекапы…

  

mistеr

8 — 29.06.16 — 12:24

  

vde69

9 — 29.06.16 — 12:28

  

jsmith

10 — 29.06.16 — 12:29

  

piter3

11 — 29.06.16 — 12:31

без логов можно гадать долго.быстрый вариант уже озвучен

  

lodger

12 — 29.06.16 — 12:33

зато теперь кто-то профинансирует закупку ИБП для сервера.

  

zak555

13 — 29.06.16 — 12:37

(7) баз много

  

6kubikov

14 — 29.06.16 — 12:37

Заодно протестируете бекапы, а то мало ли …)))

  

пипец

15 — 29.06.16 — 12:38

  

rphosts

16 — 29.06.16 — 12:43

(13) ну значит это будет несколько дольше по времени и если у вас повремянка — вам больше заплатят

  

Джинн

17 — 29.06.16 — 12:45

Сэкономили на ИБП?

  

zak555

18 — 29.06.16 — 12:45

(12) (17) не знаю

  

zak555

19 — 29.06.16 — 15:58

базы живые, как я понял побились системные

  

vde69

20 — 29.06.16 — 16:05

(19) о чем я тебе 4 часа назад написал

  

zak555

21 — 29.06.16 — 16:06

(20) да меня тут дёргают и пяти сторон )

  

Это_mike

22 — 29.06.16 — 16:13

(19) ну а бэкапы системных — не делались?

  

vde69

23 — 29.06.16 — 16:18

  

пипец

24 — 29.06.16 — 16:24

остановить скуль — покопировать бд мдфы  (а то есть вариант — что кто нибудь полезет и  потом совсем доламает)

  

zak555

25 — 29.06.16 — 16:32

(22) нет

  

zak555

26 — 29.06.16 — 16:32

(24) они копируются

  

Это_mike

27 — 29.06.16 — 16:34

  

NorthWind

28 — 29.06.16 — 22:23

(0) жесткой посадки скуль не любит от слова «совсем». Ваше счастье, что есть бэкапы. Переустанавливайте и накатывайте.

  

Дебет

29 — 30.06.16 — 05:04

переустанови скул и приатач базы

  

Dmitry1c

30 — 30.06.16 — 06:12

было такое. таблица config умерла, или как-то так в скуле

  

Dmitry1c

31 — 30.06.16 — 06:13

(30) *masters

  

zak555

32 — 30.06.16 — 06:42

(29) вся проблема в том, что установщик виндоус не работает

  

Chameleon1980

33 — 30.06.16 — 07:01

да зравствует ибп

  

vde69

34 — 30.06.16 — 07:41

  

zak555

35 — 30.06.16 — 08:07

  

zak555

36 — 30.06.16 — 08:08

(34) всегда считал, что переустановка винды самая крайняя мера

  

vde69

37 — 30.06.16 — 08:22

  

zak555

38 — 30.06.16 — 08:23

  

vde69

39 — 30.06.16 — 08:24

попробуй repaint скуля а не полный снос

  

vde69

40 — 30.06.16 — 08:25

(38) на самом деле это не твоя ответственность, можешь пиво пить, пусть админ бегает…

  

zak555

41 — 30.06.16 — 08:31

(39) аналогичная ошибка

  

zak555

42 — 30.06.16 — 08:32

(40) а можно будет ещё и на it-сопровождение взять )

  

Cyberhawk

43 — 30.06.16 — 08:32

Так службу-то включи

  

zak555

44 — 30.06.16 — 08:32

(43) она включена

  

Cyberhawk

45 — 30.06.16 — 08:32

C:WINDOWSsystem32msiexec.exe в процессах есть?

  

vde69

46 — 30.06.16 — 08:34

  

zak555

47 — 30.06.16 — 08:34

  

Cyberhawk

48 — 30.06.16 — 08:35

(47) Под кем служба запущена? SYSTEM / Local System?

  

vde69

49 — 30.06.16 — 08:36

(47) тогда хз чего там у тебя, покопай логи винды…

  

Cyberhawk

50 — 30.06.16 — 08:38

  

zak555

51 — 30.06.16 — 08:40

(48) позже смогу посмотреть

  

zak555

52 — 30.06.16 — 08:40

  

Cyberhawk

53 — 30.06.16 — 08:42

  

zak555

54 — 30.06.16 — 08:44

(53) и эту ссылку  тоже пробовали

  

vde69

55 — 30.06.16 — 08:44

  

zak555

56 — 30.06.16 — 08:47

  

vde69

57 — 30.06.16 — 08:55

  

zak555

58 — 30.06.16 — 09:07

админ пропал, причём вместе с сервером )))

  

mistеr

59 — 30.06.16 — 09:24

(35) Копай логи винды в момент установки/удаления и логи конктерного пакета в темпе, там создается папка с GUID-ом пакета ЕМНИП.

  

piter3

60 — 30.06.16 — 09:24

весело у тебя

  

vde69

61 — 30.06.16 — 09:24

  

zak555

62 — 30.06.16 — 09:31

но что это было, так и не ясно