Исправлена ​​ошибка нехватки памяти при копировании файлов в Windows 10

Жесткий диск и оперативная память играют важную роль в выполнении любых операций на компьютере. Каждая задача или процесс, происходящий в компьютере, требует некоторого объема оперативной памяти, а также жесткого диска для выполнения. Но иногда, когда вы копируете файлы из одного места в другое, вы можете получить одно из следующих сообщений:

• Недостаточно памяти или системных ресурсов. Закройте некоторые окна или программы и повторите попытку.
• Недостаточно памяти для выполнения этой операции – копирования файлов.

Эта ошибка возникает из-за ограничения кучи рабочего стола , когда недостаточно памяти для выполнения этой операции при копировании файлов. Сегодня мы рассмотрим возможные исправления для увеличения этого предела и, в конечном счете, исправим эту ошибку в Windows 10.

Ну, закройте все открытые окна и программы и попробуйте скопировать снова и посмотреть, поможет ли это. Если это не так, следуйте нашему предложению.

Ошибка нехватки памяти при копировании файлов

Прежде чем начать, вы можете сначала создать точку восстановления системы, поскольку это может помочь вам отменить нежелательные или нежелательные изменения.

Мы будем использовать редактор реестра, чтобы исправить эту проблему. Запустите regedit и нажмите Enter. После открытия редактора реестра перейдите к следующему

Компьютер \ HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Диспетчер сеансов \ Подсистемы

Дважды щелкните DWORD с именем Windows , чтобы изменить его.

В поле Значение данных необходимо изменить значения для SharedSection .

Это будет в формате,

Вам нужно изменить значение bbbb и cccc.

• В случае, если вы используете операционную систему x86, задайте для bbbb значение 12288 и значение для cccc до 1024.
• В случае, если вы используете операционную систему x64, задайте для bbbb значение 20480 и значение для cccc до 1024.

Выйдите из редактора реестра и перезагрузите компьютер, чтобы изменения вступили в силу.

Значение bbbb в реестре SharedSection – это размер кучи рабочего стола для каждой станции интерактивного окна, тогда как раздел cccc значения SharedSection – это размер кучи рабочего стола для каждой неинтерактивной станции окна. Вы также должны знать, что установка значения bbbb больше чем 20480 КБ вообще не рекомендуется.

Исправлена ​​ли ваша проблема сейчас?

Инжект кода средствами CSRSS: Сказ о том, как Windows 7 помогает современным хакерам старыми средствами

Содержание статьи

Существует такая аксиома: чем больше недокументирована какая-нибудь часть Windows, тем больше разработчики Microsoft не хотят, чтобы ее использовали разработчики программного обеспечения. Причина как всегда банальна – недокументированные возможности позволяют вытворять с системой жуткие вещи!

Тем не менее в среде программистов бытует мнение, что, несмотря на полную недокументированность подсистемы ввода-вывода CSRSS, ничего интересного она из себя не представляет, как с точки зрения прикладного кодинга, так и с точки зрения разработки малвари. Да, приходится признать, что даже вирусам и руткитам она неинтересна. За исключением, пожалуй, знаменитого червя Nimda. Хотя, постой, еще существует способ детекта скрытых процессов возможностями CSRSS… В общем, CRRSS не так прост и бесполезен, как кажется некоторым несознательным гражданам. Положим его на наш операционный стол и узнаем, чем же он может быть полезен настоящему хакеру.

Введение

Подсистема CSRSS – client/server run-time subsystem (клиент-серверная подсистема) – это часть исполнительной подсистемы Windows, которая отвечает за консольные приложения, создание/удаление потоков и за 16-битную виртуальную среду MS-DOS. Это мы знаем, но, к сожалению, на этом вся документированность CSRSS заканчивается.

Наверное, это один из самых загадочных кирпичиков Windows. И это не только загадочный, но и чувствительный кирпичик, так как процесс CSRSS.EXE – единственный, которому присваивается эпитет «критичный», и вмешательство в его нормальное исполнение грозит крахом всей системы. Упомяну такую деталь – на весь (!) зоопарк BSOD’ов, который только может сгенерировать ядро Windows, только два багчека: 0x0000004C (FATAL_UNHANDLED_HARD_ERROR) и 0xC000021A (STATUS_SYSTEM_PROCESS_TERMINATED) происходят при крахе его юзермодных процессов – это процессы winlogon.exe и csrss.exe. Без этих двух процессов Windows существовать не может. И самое печальное – во втором случае, если будет установлено, что причиной «синего экрана» стал отказ csrss.exe (как правило, в результате действия малвари), то это будет фатальный случай, приводящий к переустановке системы (или ее аварийному восстановлению).

CSRSS берет свои настройки не из реестра, как может показаться на первый взгляд, а из командной строки, которая выглядит примерно так:

%SystemRoot%system32csrss.exe ObjectDirectory=Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

В общем, на мой взгляд, основная задача CSRSS все-таки заключается в своеобразном контроле над созданием и уничтожением процессов и потоков. А раз так, то нельзя недооценивать те возможности, которые в нем скрыты.

LPC, или Local Procedure Calls

Перед тем, как углубиться в дебри CsrApi, давай посмотрим в сторону механизма LPC, созданного в Windows для реализации межпроцессного взаимодействия. Почему именно на него? Все дело в том, что CSRSS реализует свой собственный протокол поверх LPC. LPC часто называют Local InterProcess Communication. Я, к сожалению, не знаю, как на самом деле расшифровывается LPC, но раз на MSDN-блогах LPC зовут Local Procedure Calls, значит, так тому и быть.

Как уже было сказано выше, LPC – это недокументированный механизм Windows, предназначенный для взаимодействия между процессами и потоками, основанный на приеме/передаче пакетов. Это взаимодействие может происходить как целиком в ядре, так и между юзермодными компонентами.

Суть LPC предельно проста – коммуникация между участниками взаимодействия (клиентом и сервером) осуществляется путем передачи блоков данных (так называемых сообщений LPC) . Клиентом может быть поток или процесс, и исполняться они могут на разных ring-уровнях, как в ядре (r0), так и простым пользовательским приложением (r3).

Основывается он на двух вещах – портах и внутренних LPC-структурах, таких как PORT_MESSAGE. Логически LPC состоит из двух действий – коннекта к определенному порту (NtCreatePort, NtConnectPort, NtListenPort и т.д.) и передаче данных (NtRequestWaitReplyPort и др.).

CsrClientCallServer – вот где собака порылась!

Среди всех используемых CsrApi-функций наиболее часто можно встретить CsrClientCallServer. Перекрестные ссылки на нее можно увидеть в таких функциях, как kernel32!CreateProcess, kernel32!AllocConsole, kernel32!FreeConsole, user32!EndTask и десятках других. Если мы взглянем на нее под микроскопом IDA, то увидим, что каждый раз, когда вызывается CsrClientCallServer, в стек заталкивается какое-то уникальное число, меняющееся от функции к функции:

.text:77E96D55 PUSH 4
.text:77E96D57 PUSH 20225h //

Это загадочное число – не что иное, как индекс указателя специальной функции, определенной в библиотеках, используемых подсистемой CSRSS. То есть специальная процедура, называемая CsrApiRequestThread, исполняется в контексте отдельного потока в csrss.exe, ответственного за прием запросов от пользовательской подсистемы. Она обрабатывает его через соответствующие диспетчерские таблицы CSRSS и возвращает результат.

Что интересного может дать использование функций CsrApi в интересах программиста? Много чего, например, можно организовать прямой распил консоли, так как подсистема CSRSS напрямую отвечает за консоль в Windows.

int main(int argc, char* argv[])
<
NTSTATUS Status;
CSR_API_MSG m;
CONSOLE_TITLE_MSG * consoleTitleMes = &m.u.ConsoleTitle;
CSR_CAPTURE_HEADER * сaptureBuffer;

consoleTitleMes->ConsoleHandle=GetConsoleHandle();
consoleTitleMes->TitleLen=260;
consoleTitleMes->Unicode=0;

CaptureBuffer=(CSR_CAPTURE_HEADER *)CsrAllocateCaptureBuffer(1, consoleTitleMes->TitleLen);

CsrCaptureMessageBuffer(CaptureBuffer, NULL, consoleTitleMes->TitleLen, (PVOID *)&consoleTitleMes->Title);

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

Что дальше?

Итак, что же мы нашли при распиле CSRSS? В смысле, с хакерской точки зрения. Ни много, ни мало – инжект кода в Windows 7. Как ты знаешь, разработчики Windows 7 сильно потрудились над безопасностью процессов в системе – теперь просто так выполнить CreateRemoteThread в чужой процесс не удастся. Да, приходится признать, что дяденьки из Microsoft постарались на славу, отрубив мегакулхацкерам любимый способ инжекта кода. При попытке вызова CreateRemoteThread с хэндлом процесса другого пользователя, мы обламываемся, и функция возвращает нам NULL с кодом ошибки ERROR_NOT_ENOUGH_MEMORY.
Но ведь и про старуху бывает порнуха :).

Конечно, существуют в природе способы инжекта с использованием RtlCreateUserThread (подробнее об этом можно прочитать здесь), но мы не будем его рассматривать; желающие могут поэкспериментировать сами. Не зря мы сегодня завели разговор про CSRSS, ведь именно с помощью ее возможностей можно очень даже неплохо вернуть утраченный status quo и получить возможность инжекта кода в чужие процессы. Концепция нашего PoC проста.

Дело в том, что успешность вызова CreateRemoteThread зависит от системной функции CsrClientCallServer, которая фактически обрабатывает этот запрос. Она следит за выполнением, но сама удаленный поток не создает. Вызов CreateRemoteThread сводится к системной функции NtCreateThreadEx, которая создаст поток с флагом CREATE_SUSPENDED, однако дальнейшее развитие ситуации будет зависеть от успешности вызова функции подсистемы CSRSS – CsrClientCallServer. Ничего интересного в голову не приходит? 🙂 Все, что нам нужно – это сделать так, чтобы при создании удаленного потока CsrClientCallServer всегда возвращала успешное значение. И будет тебе счастье.

Смотрим на дизассемблированную kernelbase.dll (это аналог kernel32.dll в Windows 7, если ты не знал):

kernelbase.dll
.text:7597BD24 6A 0C PUSH 0C
.text:7597BD26 68 01000100 PUSH 10001
.text:7597BD2B 53 PUSH EBX
.text:7597BD2C 8D85 F0FDFFFF LEA EAX, DWORD PTR SS:[EBP-210]
.text:7597BD32 50 PUSH EAX
.text:7597BD33 FF15 00129775 CALL NEAR DWORD PTR DS:[ ] ; ntdll.CsrClientCallServer
.text:7597BD39 8B85 10FEFFFF MOV EAX, DWORD PTR SS:[EBP-1F0]
.text:7597BD3F 8985 E8FDFFFF MOV DWORD PTR SS:[EBP-218], EAX
.text:7597BD45 399D E8FDFFFF CMP DWORD PTR SS:[EBP-218], EBX
.text:7597BD4B 0F8C 13D80100 JL KERNELBA.75999564

Нам нужно найти в памяти kernelbase.dll, просканировать таблицу импорта, найти адрес импортируемой функции CsrClientCallServer и подменить его новым указателем на заранее подготовленную функцию CsrClientCallServer, которая всегда будет возвращать «успех». Сделать это легко. Смотрим:

ULONG NewCsrClientCallServer(PVOID Arg1, PVOID Arg2, ULONG Arg3, ULONG Arg4)
<
*( DWORD *)(( BYTE *)Arg1 + 0x20 ) = 0;
return 0;
>

.
DWORD ImportAddress, OriginalCsrClientCallServer, OldProtect;
ImportAddress = GetImportAddressFromIat(GetModuleHandle(«kernelbase.dll»), «CsrClientCallServer»);
VirtualProtect(( VOID ) ImportAddress, sizeof(DWORD), PAGE_EXECUTE_READWRITE, &OldProtect);
OriginalCsrClientCallServer = *(DWORD)ImportAddress;
(DWORD)ImportAddress=(DWORD)NewCsrClientCallServer;
.

И все! Раз, раз, раз – и… мы в дамках! Теперь наша новая функция CsrClientCallServer будет возвращать «success», что, собственно, и нужно для успешного запуска CreateRemoteThread. Кстати, такой подход довольно оригинален: вместо того, чтобы искать способы выполнения своего кода, писать (или покупать) 0day-эксплойты, повышающие права, искать новые уязвимости в системе и т.д., иногда бывает просто нужно переписать один байт. Самое главное – знать, где 🙂

В заключение только добавлю, что для успешного выполнения такого кода нужны дебаг-привилегии, которые подрубаются примерно таким образом:

unsigned long GetDebugPrivileges()
<
TOKEN_PRIVILEGES tokenPrvlgs;

tokenPrvlgs.PrivilegeCount = 1;
tokenPrvlgs.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
if(!AdjustTokenPrivileges(hToken, FALSE, &tokenPrvlgs, 0, NULL, NULL))
<
return error;
>

CloseHandle( hToken );
return success;
>

Вот и все, что я хотел донести до тебя. Не так страшна Windows 7, как ее раскрашивают. Код, который делает все вышеизложенное, как всегда, ищи на диске. Удачного компилирования, и да пребудет с тобой Сила!

P.S. Осторожнее в экспериментах с CSRSS! А то систему жалко :).

На компакт-диске ты найдешь реализацию описанных в статье приемов на С.

Не ленись читать MSDN – несмотря на бытующее в определенных кругах пренебрежительное отношение к данному сайту, чтение его статей позволяет устранить до 99% ошибок, возникающих при использовании WinAPI.

Ошибка при запуске многих приложений COM+: код ошибки 80080005 — сбой выполнения сервера

В этой статье приводится обходное решение проблемы, из которой при запуске многих приложений Microsoft COM+ вручную из оснастки консоли управления (MMC) служб компонентов вы получаете код ошибки 80080005.

Исходная версия продукта: Windows Server 2012 R2
Исходный номер КБ: 870655

Симптомы

При запуске многих приложений Microsoft COM+ вручную из оснастки консоли управления (MMC) служб компонентов, где каждое приложение COM+ работает под другой учетной записью пользователя, может появиться следующее сообщение об ошибке:

Ошибка каталога: ошибка при обработке последней операции. Код ошибки 80080005 — сбой выполнения сервера. Журнал событий может содержать дополнительные сведения об устранении неполадок.

Вы получите сообщение об ошибке, аналогичное следующему в журнале приложения просмотра событий:

Категории: None (нет)
ИД события: 10010

Пользователь: СИСТЕМА NT \ AUTHORITY

Описание: сервер не зарегистрирован в DCOM в течение необходимого времени.

Причина

Если многие приложения COM+ работают под разными учетными записями пользователей, указанными в свойстве This User, компьютер не может выделить память для создания новой кучи рабочего стола для нового пользователя. Поэтому процесс не может начаться.

Обходной путь

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о том, как создать и восстановить реестр, см. в этой теме.

Чтобы обойти эту проблему, измените значение следующего поднажатия реестра:

Для этого выполните следующие действия:

Щелкните Пуск, затем Выполнить и введите regedit. Затем нажмите ОК.

Открыв редактор реестра, выберите следующий подраздел:

По умолчанию запись Windows в подмайке имеет значение, аналогичное следующему (все в одной строке):

%SystemRoot% \ system32 \csrss.exe ObjectDirectory= \ Windows SharedSection=1024,3072 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

Щелкните правой кнопкой мыши запись Windows и выберите пункт «Изменить». Появится диалоговое окно «Изменение строки».

В поле данных «Значение» найдите SharedSection, добавьте в SharedSection значение 512 и нажмите кнопку «ОК».

Только что измененная запись Windows читается следующим образом:

%SystemRoot% \ system32 \csrss.exe ObjectDirectory= \ Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

Действия для воспроизведения поведения

Создайте на компьютере 100 различных локальных учетных записей пользователей.

Откройте оснастку MMC «Службы компонентов». Для этого выполните следующие действия:

1. Нажмите кнопку Пуск, выделите пункт Настройка и выберите Панель управления.
2. В панели управления дважды щелкните «Администрирование» и дважды щелкните компонент «Службы». Появится оснастка MMC «Службы компонентов».
3. В левой области раз expand Component Services, expand Computers, and then expand My Computer.

Создайте приложение COM+, а затем установите удостоверение приложения COM+. Для этого выполните следующие действия:

1. Щелкните правой кнопкой мыши приложения COM+, найдите пункт «Новый» и выберите пункт «Приложение». Появится диалоговое окно мастера установки com-приложений.
2. В диалоговом окне мастера установки приложений COM нажмите кнопку «Далее». Появится диалоговое окно «Установка или создание нового приложения».
3. Щелкните «Создать пустое приложение». Появится диалоговое окно «Создание пустого приложения».
4. В поле «Введите имя нового приложения» введите MyCOM1 и нажмите кнопку «Далее». Появится диалоговое окно «Настройка удостоверения приложения».
5. Щелкните этого пользователя и введите имя пользователя, созданное на шаге 1, в поле «Пользователь».
6. В диалоговом окне «Настройка удостоверения приложения» введите пароль в поле «Пароль» и «Подтверждение пароля» и нажмите кнопку «Далее». Появится диалоговое окно «Благодарим вас за использование мастера установки приложений COM».
7. Нажмите кнопку Готово.

Добавьте компонент в приложение COM+. Для этого выполните следующие действия:

1. В левой области оснастки MMC «Службы компонентов» разорвате myCom1.
2. Щелкните правой кнопкой мыши «Компоненты», найдите пункт «Новый» и выберите «Компонент». Появится диалоговое окно «Мастер установки компонентов COM».
3. Нажмите кнопку Далее. Появится диалоговое окно «Импорт или установка компонента».
4. Щелкните «Импорт компонентов», которые уже зарегистрированы. Появится диалоговое окно «Выбор компонентов для импорта».
5. В списке компонентов «Мой компьютер» щелкните компонент и нажмите кнопку «Далее». Появится диалоговое окно «Благодарим вас за использование мастера установки приложений COM».
6. Нажмите кнопку Готово.

Повторите шаг 3, чтобы создать 100 приложений COM+, которые работают под разными локальными учетные записи пользователей.

Повторите шаг 4, чтобы добавить компоненты в 100 приложений COM+, созданных на шаге 5.

В левой области оснастки MMC «Службы компонентов» щелкните правой кнопкой мыши каждое созданное приложение COM+ и выберите «Начните». После запуска некоторых приложений COM+ вы получите сообщение об ошибке, описанное в разделе «Признаки».