Лучший отвечающий
Сбой MS Excel 2010. Связано с автосохранением. Excel "съедает" около 800Мб памяти.

Вопрос
-
Доброго времени суток %username%. С ходу к делу.
ОС - Windows7 prof 32bit
MS Office 2010 32bit
Работа ведется в системе, с файлами формата xlsx размером от 50Кб до 20Мб. Файлы располагаются физически на сетевом хранилище (диски серверов). В файлах очень много ссылок, они все между собой связаны в формулах, отчетах и т.п. Т.е. в формулах используются ссылки на другие ячейки в других листах, файлах.
С определенного момента начала проявляться проблема. Периодически файлы "зависают". Excel перестает отвечать на запросы. В результате либо перезапускается автоматически, либо сбрасывается через диспетчер задач. Как результат проявления - сбиваются ссылки, вместо сетевого ресурса, указывается локальный путь типа c:\%userprofail%\.... собственно и работа сотрудников теряется.
После наблюдения, проявилась закономерность, и выявлены ошибки:
В течение работы с файлом, объем занятой памяти ~50Мб, Срабатывает автосохранение, и появляется предупреждение "Возникла непридвиденная ошибка. В этом сеансе работы с Excel автовосстановление отключено". После этого, занимаемый ресурс памяти в диспетчере задач резко возрастает до ~750Мб. Приложение "зависает".
В эвентах существуют такие вещи:
Имя журнала: Application
Источник: Application Error
Дата: 01.09.2011 16:22:57
Код события: 1000
Категория задачи:(100)
Уровень: Ошибка
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: 12.domain-local.ru
Описание:
Имя сбойного приложения: EXCEL.EXE, версия: 14.0.4756.1000, отметка времени: 0x4b9c08e8
Имя сбойного модуля: EXCEL.EXE, версия: 14.0.4756.1000, отметка времени 0x4b9c08e8
Код исключения: 0xc0000005
Смещение ошибки: 0x00b90ce1
Идентификатор сбойного процесса: 0x1780
Время запуска сбойного приложения: 0x01cc6887058840c6
Путь сбойного приложения: C:\Program Files\Microsoft Office\Office14\EXCEL.EXE
Путь сбойного модуля: C:\Program Files\Microsoft Office\Office14\EXCEL.EXE
Код отчета: fa329272-d47b-11e0-a585-6c626d5a5fc3
Источник: Windows Error Reporting
Дата: 01.09.2011 16:23:00
Код события: 1001
Категория задачи:Отсутствует
Уровень: Сведения
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: 12.domain-local.ru
Описание:
Контейнер ошибки , тип 0
Имя события: APPCRASH
Ответ: Нет данных
Идентификатор CAB: 0
Сигнатура проблемы:
P1: EXCEL.EXE
P2: 14.0.4756.1000
P3: 4b9c08e8
P4: EXCEL.EXE
P5: 14.0.4756.1000
P6: 4b9c08e8
P7: c0000005
P8: 00b90ce1
P9:
P10:
Вложенные файлы: "......используемые файлы".
Как я понимаю, придется вообще отключить автосохранение? Или есть какие либо пути решения проблемы иначе?
2 сентября 2011 г. 8:59
Ответы
-
Ну возможно сетевой путь (типа \\server\share\path1\...\path10\Long file name.xlsx) все же короче, чем тот, который получается при автосохранении (типа c:\%userprofile%\Long file name.xlsx). А при "ручном" сохранении каталог автовосстановления не используется, файл сохраняется напрямую.
Поэтому я и советовал попробовать изменить каталог автовосстановления по умолчанию на какой-нибудь другой типа c:\bkp.- Предложено в качестве ответа Sergey Plotnikov 8 сентября 2011 г. 10:49
- Помечено в качестве ответа Vinokurov YuriyModerator 3 октября 2011 г. 6:32
8 сентября 2011 г. 2:48
Все ответы
-
Ошибка возникает, скорее всего, из-за потери пути к каталогу автовосстановления. В вашей ситуации для начала действительно придется отключить автосохранение, потом настроить каталог автовосстановления и тестировать потихонечку. Вообще, судя по вашему описанию вам уже нужно заводить базу данных - душевле обойдется, чем содержать неимоверное количество листов и листиков Excel, сдувать с них пыль и регулярно восстанавливать всю эту хрупкую конструкцию после обрушения.
Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
Посетите Блог Инженеров Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html5 сентября 2011 г. 13:45Модератор -
Думаю что автосохранение придется совсем отключить.
Лично моя мысль следущая: после сбоя, автосохранение вытаскивает из профиля "автосохраненный файл" и в случае глупой комманды заменяющей исходный файл, автосохраненным, естественно бьются все ссылки.
Юрий, что Вы имеете ввиду под фразой "настроить каталог автосохранения"? Он по умолчанию в профиле. Думаю как раз искомая проблема, именно в использовании автосохранения для таких файлов. В общем то и будет как решение вопроса - отключение автосохранения. Но вопрос тогда в другом, должно ли так быть, что при попытке автосохранения приложение занимает столько ресурсов, и почему.
И подскажите, я конечно мог не правильно понять, Excel можно "подсадить" на базу данных? Я такого не знаю, честно говоря. Просто пользователи настолько удовлевторены работой этого приложения, что "подпихнуть" им другое сложно. Что бы Вы посоветовали сделать в этой ситуации?
7 сентября 2011 г. 1:04 -
Илья, для тестовых целей я бы предложил перенацелить каталог восстановления на сетевой диск у одного из пользователей. Касательно того, почему приложение занимает столько ресурсов - у вас сервера не на базе Server 2003? Если да, то на клиентах проделайте netsh interface tcp set global autotuninglevel=disabled и понаблюдайте.
Касательно подключения Excel к базе данных: большинство БД может использоваться в качестве источника данных для Excel (см. Создание и редактирование подключений к внешним данным и управление ими). Однако, я имел в виду то, что при вашей достаточно сложной структуре расположения данных (если я правильно понял вашу ситуацию) целесообразнее уже будет обзаводиться СУБД собственной или сторонней разработки для управления всеми этими таблицами, отчетами и т.д. Excel - штука хорошая, но ваша задача для него смотрится уже излишне масштабной.
Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
Посетите Блог Инженеров Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html7 сентября 2011 г. 7:09Модератор -
Илья, у нас пользователи тоже используют файлы Excel со множеством перекрестных связей в разных версиях Office (2003, 2007, 2010), но подобных проблем ни у кого не наблюдалось, хотя автосохранение у всех включено. Есть несколько мыслей по поводу возможной причины этих проблем:
1) возможно проблема все же связана с каталогом автовосстановления, например, с правами или со свободным местом - в общем, я бы попробовал поменять его расположение;
2) слишком длинные имена файлов - при работе с сетевыми файлами имена файлов формируются в виде \\server\share\path1\...\path10\Long file name.xlsx, даже если сетевой диск подключен на какую-либо букву. Кстати, если сетевой путь не очень длинный, то при автосохранении он может значительно увеличится за счет c:\%userprofile%\... Кроме того, есть подозрение, что с русскими именами Excel работает в Юникоде, что дополнительно увеличивает длину имени файлов. А при превышении ограничения на длину имени файла (218 знаков) последствия могут быть самые непредсказуемые, в том числе и описанные в вопросе и не всегда Excel выдаст ошибку, указывающую на длину имени. Соответственно, рекомендацией будет - максимально сократить имена файлов и каталогов, в т.ч. каталога автовосстановления;
3) автономные файлы - теоретически тоже может являться источником проблем, поэтому я бы также отключил эту функцию для сетевого каталога на сервере.
И для полноты эксперимента я бы перенес набор связанных между собой файлов на локальный диск (в папку с коротким именем) и посмотрел как работает автосохранение в данном случае.
А отключать автосохранение - это, на мой взгляд, не выход :)
- Изменено Sergey Plotnikov 7 сентября 2011 г. 10:11
7 сентября 2011 г. 10:09 -
to Юрий.
Серверы 2008, 2008r2. Попробую варинаты с БД. Спасибо.
to Сергей.
1 пункт - наверное отпадает. Места на диске довольно. Права в локальный профиль пользователя (там же каталог автосохранения), он там царь и Бог.
2 - вероятно, все файлы в кириллице. Все пути, названия оооочень длинные. Соответственно ссылки так же. Пересохранять/уменьшать/сокращать имена файлов...не вариант, там уже не сотни, а тысячи ссылок.
Ну и собственно переносить файлы на локальный диск, тоже..из раздела фантастики.
Спасибо за советы, буду ждать еще варианты ответов.
7 сентября 2011 г. 10:39 -
2 - вероятно, все файлы в кириллице. Все пути, названия оооочень длинные. Соответственно ссылки так же. Пересохранять/уменьшать/сокращать имена файлов...не вариант, там уже не сотни, а тысячи ссылок.
Ну тогда причина на 90% в этом. А для переименования (изменения ссылок и т.д.) можно написать макрос ;)
А переносить все эти файлы на локальный диск само собой ни к чему - это нужно только для проверки (поскольку проблема похоже связана с автосохранением только косвенно).
7 сентября 2011 г. 11:31 -
Да, в это может быть причина, но почему тогда ручное сохранение не вызывает проблем. А офис "подвисает" в момент автосохранения?
Макрос? В своих силах, в столь тонком вопросе я не уверен, это финансовые документы, любой сбой повлечет за собой конкретные денежные проблемы. Пусть с финансами, работают финансисты. :) Моя задача обеспечить их работу.
8 сентября 2011 г. 2:11 -
Ну возможно сетевой путь (типа \\server\share\path1\...\path10\Long file name.xlsx) все же короче, чем тот, который получается при автосохранении (типа c:\%userprofile%\Long file name.xlsx). А при "ручном" сохранении каталог автовосстановления не используется, файл сохраняется напрямую.
Поэтому я и советовал попробовать изменить каталог автовосстановления по умолчанию на какой-нибудь другой типа c:\bkp.- Предложено в качестве ответа Sergey Plotnikov 8 сентября 2011 г. 10:49
- Помечено в качестве ответа Vinokurov YuriyModerator 3 октября 2011 г. 6:32
8 сентября 2011 г. 2:48 -
Изменил по Вашему предложению, включил автосохранение в папку c:\save, сотрудник работает больше 4 часов, пока проблем не замечено. Но не ясно, срабатывает автосохранение или нет. Думаю что срабатывает. Но опять же получается временное решение, пока имена файлов не удлиняться, и пути к ним не превысят критичные.
Пока страхуюсь полуторочасовыми резервными копиями.
8 сентября 2011 г. 8:48 -
А зачем их удлинять? Их укорачивать надо :)
Как правило, люди заносят в имя файла массу ненужной информации - им нужно просто предложить какую-то продуманную систему именования.
8 сентября 2011 г. 10:52 -
Пользователям этого не пояснишь. Длина будет расти. Хотя попробуем изменить этот вопрос.
Пока все в режиме тестирования, проверяем вышеуказанный вариант.
12 сентября 2011 г. 1:38 -
Я так понял, что автосохранение в папку c:\save помогло?15 сентября 2011 г. 10:05
-
Нет, помогло только отключение Автосохранения. Потому как ссылки в файле все равно бились, при попытке восстановиться с "автосохраненного" файла.
- Изменено Ilya Morozov 20 октября 2011 г. 3:27
20 октября 2011 г. 3:26