none
Сбой MS Excel 2010. Связано с автосохранением. Excel "съедает" около 800Мб памяти. RRS feed

 > 

  • Вопрос

  • Question
    Нужно войти
    0
    Нужно войти

    Доброго времени суток %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
    |

Ответы

  • Question
    Нужно войти
    1
    Нужно войти

    Ну возможно сетевой путь (типа \\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
    |

Все ответы

  • Question
    Нужно войти
    1
    Нужно войти
    Ошибка возникает, скорее всего, из-за потери пути к каталогу автовосстановления. В вашей ситуации для начала действительно придется отключить автосохранение, потом настроить каталог автовосстановления и тестировать потихонечку. Вообще, судя по вашему описанию вам уже нужно заводить базу данных - душевле обойдется, чем содержать неимоверное количество листов и листиков Excel, сдувать с них пыль и регулярно восстанавливать всю эту хрупкую конструкцию после обрушения.
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow MSTechnetForum on Twitter

    Посетите Блог Инженеров Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html
    5 сентября 2011 г. 13:45
    |
    Модератор
  • Question
    Нужно войти
    0
    Нужно войти

    Думаю что автосохранение придется совсем отключить.

    Лично моя мысль следущая: после сбоя, автосохранение вытаскивает из профиля "автосохраненный файл" и в случае глупой комманды заменяющей исходный файл, автосохраненным, естественно бьются все ссылки.

    Юрий, что Вы имеете ввиду под фразой "настроить каталог автосохранения"? Он по умолчанию в профиле. Думаю как раз искомая проблема, именно в использовании автосохранения для таких файлов. В общем то и будет как решение вопроса - отключение автосохранения. Но вопрос тогда в другом, должно ли так быть, что при попытке автосохранения приложение занимает столько ресурсов, и почему.

    И подскажите, я конечно мог не правильно понять, Excel можно "подсадить" на базу данных? Я такого не знаю, честно говоря. Просто пользователи настолько удовлевторены работой этого приложения, что "подпихнуть" им другое  сложно. Что бы Вы посоветовали сделать в этой ситуации?

    7 сентября 2011 г. 1:04
    |
  • Question
    Нужно войти
    1
    Нужно войти

    Илья, для тестовых целей я бы предложил перенацелить каталог восстановления на сетевой диск у одного из пользователей. Касательно того, почему приложение занимает столько ресурсов - у вас сервера не на базе Server 2003? Если да, то на клиентах проделайте netsh interface tcp set global autotuninglevel=disabled и понаблюдайте.

    Касательно подключения Excel к базе данных: большинство БД может использоваться в качестве источника данных для Excel (см. Создание и редактирование подключений к внешним данным и управление ими). Однако, я имел в виду то, что при вашей достаточно сложной структуре расположения данных (если я правильно понял вашу ситуацию) целесообразнее уже будет обзаводиться СУБД собственной или сторонней разработки для управления всеми этими таблицами, отчетами и т.д. Excel - штука хорошая, но ваша задача для него смотрится уже излишне масштабной.

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow MSTechnetForum on Twitter

    Посетите Блог Инженеров Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html
    7 сентября 2011 г. 7:09
    |
    Модератор
  • Question
    Нужно войти
    1
    Нужно войти

    Илья, у нас пользователи тоже используют файлы Excel со множеством перекрестных связей в разных версиях Office (2003, 2007, 2010), но подобных проблем ни у кого не наблюдалось, хотя автосохранение у всех включено. Есть несколько мыслей по поводу возможной причины этих проблем:

    1) возможно проблема все же связана с каталогом автовосстановления, например, с правами или со свободным местом - в общем, я бы попробовал поменять его расположение;

    2) слишком длинные имена файлов - при работе с сетевыми файлами имена файлов формируются в виде \\server\share\path1\...\path10\Long file name.xlsx, даже если сетевой диск подключен на какую-либо букву. Кстати, если сетевой путь не очень длинный, то при автосохранении он может значительно увеличится за счет c:\%userprofile%\... Кроме того, есть подозрение, что с русскими именами Excel работает в Юникоде, что дополнительно увеличивает длину имени файлов. А при превышении ограничения на длину имени файла (218 знаков) последствия могут быть самые непредсказуемые, в том числе и описанные в вопросе и не всегда Excel выдаст ошибку, указывающую на длину имени. Соответственно, рекомендацией будет - максимально сократить имена файлов и каталогов, в т.ч. каталога автовосстановления;

    3) автономные файлы - теоретически тоже может являться источником проблем, поэтому я бы также отключил эту функцию для сетевого каталога на сервере.

    И для полноты эксперимента я бы перенес набор связанных между собой файлов на локальный диск (в папку с коротким именем) и посмотрел как работает автосохранение в данном случае.

    А отключать автосохранение - это, на мой взгляд, не выход :)

    7 сентября 2011 г. 10:09
    |
  • Question
    Нужно войти
    0
    Нужно войти

    to Юрий.

    Серверы 2008, 2008r2. Попробую варинаты с БД. Спасибо.

    to Сергей.

    1 пункт - наверное отпадает. Места на диске довольно. Права в локальный профиль пользователя (там же каталог автосохранения),  он там царь и Бог.

    2 - вероятно, все файлы в кириллице. Все пути, названия оооочень длинные. Соответственно ссылки так же. Пересохранять/уменьшать/сокращать имена файлов...не вариант, там уже не сотни, а тысячи ссылок.

    Ну и собственно переносить файлы на локальный диск, тоже..из раздела фантастики.

    Спасибо за советы, буду ждать еще варианты ответов.

    7 сентября 2011 г. 10:39
    |
  • Question
    Нужно войти
    0
    Нужно войти

    2 - вероятно, все файлы в кириллице. Все пути, названия оооочень длинные. Соответственно ссылки так же. Пересохранять/уменьшать/сокращать имена файлов...не вариант, там уже не сотни, а тысячи ссылок.

    Ну тогда причина на 90% в этом. А для переименования (изменения ссылок и т.д.) можно написать макрос ;)

    А переносить все эти файлы на локальный диск само собой ни к чему - это нужно только для проверки (поскольку проблема похоже связана с автосохранением только косвенно).

    7 сентября 2011 г. 11:31
    |
  • Question
    Нужно войти
    0
    Нужно войти

    Да, в это может быть причина, но почему тогда ручное сохранение не вызывает проблем. А офис "подвисает" в момент автосохранения?

    Макрос? В своих силах, в столь тонком вопросе я не уверен, это финансовые документы, любой сбой повлечет за собой конкретные денежные проблемы. Пусть с финансами, работают финансисты. :) Моя задача обеспечить их работу.

    8 сентября 2011 г. 2:11
    |
  • Question
    Нужно войти
    1
    Нужно войти

    Ну возможно сетевой путь (типа \\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
    |
  • Question
    Нужно войти
    0
    Нужно войти

    Изменил по Вашему предложению, включил автосохранение в папку c:\save, сотрудник работает больше 4 часов, пока проблем не замечено. Но не ясно, срабатывает автосохранение или нет. Думаю что срабатывает. Но опять же получается временное решение, пока имена файлов не удлиняться, и пути к ним не превысят критичные.

    Пока страхуюсь полуторочасовыми резервными копиями.

    8 сентября 2011 г. 8:48
    |
  • Question
    Нужно войти
    0
    Нужно войти

    А зачем их удлинять? Их укорачивать надо :)

    Как правило, люди заносят в имя файла массу ненужной информации - им нужно просто предложить какую-то продуманную систему именования.

    8 сентября 2011 г. 10:52
    |
  • Question
    Нужно войти
    0
    Нужно войти

    Пользователям этого не пояснишь. Длина будет расти. Хотя попробуем изменить этот вопрос.

    Пока все в режиме тестирования, проверяем вышеуказанный вариант.

    12 сентября 2011 г. 1:38
    |
  • Question
    Нужно войти
    0
    Нужно войти
    Я так понял, что автосохранение в папку c:\save помогло?
    15 сентября 2011 г. 10:05
    |
  • Question
    Нужно войти
    0
    Нужно войти
    Нет, помогло только отключение Автосохранения. Потому как ссылки в файле все равно бились, при попытке восстановиться с "автосохраненного" файла.
    • Изменено Ilya Morozov 20 октября 2011 г. 3:27
    20 октября 2011 г. 3:26
    |