Ошибка r6016 not enough space for thread data что делать

Hi,

I would like to suggest you install the latest version of service pack for Windows Small Business Server 2003 to check the result.

According to the following Microsoft KB article, service pack can fix some w3wp.exe issue.

The W3wp.exe process consumes up to 99 percent of the CPU resources every several minutes on a Windows Server 2003-based computer

http://support.microsoft.com/kb/900243

Regards,

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

• Marked as answer by

  Monday, August 15, 2011 4:45 AM

Hi,

I would like to suggest you install the latest version of service pack for Windows Small Business Server 2003 to check the result.

According to the following Microsoft KB article, service pack can fix some w3wp.exe issue.

The W3wp.exe process consumes up to 99 percent of the CPU resources every several minutes on a Windows Server 2003-based computer

http://support.microsoft.com/kb/900243

Regards,

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

• Marked as answer by

  Monday, August 15, 2011 4:45 AM

«JDWeng,  I agree with everything you just said»

Except that what he says has little to do with your problem…

«The error you are getting is caused by an access to a memory location outside the bounds that the operating system is allowing and causing an exception.  So any type error that accesses a invalid memory error can be causing this problem.»

Oh well, that sounds like the description of an access violation exception. Too bad that the error you are seeing has nothing to do with access violation or any other exception.

R6016 is a error generated by the VC runtime. The source of the C runtime is included with Visual Studio (check the VS installation folderVCcrtsrc). That means you could take a look at it and get an idea about what’s going on. Here’s what I found after
a quick look:

1. This error can occur during app startup when the (non dll) C runtime is initialized. This seems to match your situation because you statically link the C runtime.

But this initialization occurs before your code gets a chance to run and the possible reasons for this include lack of memory and lack of TLS slots. I’m not sure how that can happen during at app startup, that would mean that the system itself is toast.

2. This error can also happen when you create a thread by using CreateThread or any other function which doesn’t use _beginthtread/_beginthreadex. To be precise, you won’t get this error when the thread is created, you’ll get this error later when you try
to access some CRT functionality which requires a per thread data structure.

The typical reason for failure in this situation is lack of memory but that thread data structure is 100-200 bytes in size, I find it hard to believe that exactly this allocation fails, surely there are other allocations of roughly the same size
in your program.

Another reason could be failure of TlsSetValue caused by memory corruption but this seems unlikely too, you would have to be terrible unlucky to corrupt exactly the memory used by the TLS storage.

So, do you at least know what this error occurs? Does it happen during application startup or later?

• Marked as answer by

  Thursday, January 23, 2014 4:24 AM

It has nothing to do with the stack either.

Here are 2 ways to reproduce R6016:

#include <cstring>

extern "C" extern unsigned long __flsindex;

int main() {
	__flsindex = 4200;
	strtok("foo", "bar");
}

This one simply «corrupts» the CRT’s __flsindex variable, this will prevent the runtime from retrieving the per thread data even if the data was already allocated.

#include <cstring>
#include <windows.h>

DWORD WINAPI ThreadProc(LPVOID p) {
	HANDLE hHeap = GetProcessHeap();
	for (void *p; (p = HeapAlloc(hHeap, 0, 50000)) != nullptr; )
		;
	for (void *p; (p = HeapAlloc(hHeap, 0, 50)) != nullptr; )
		;

	strtok("foo", "bar");
	return 0;
}

int main() {
	HANDLE hThread = CreateThread(nullptr, 0, ThreadProc, nullptr, 0, nullptr);
	WaitForSingleObject(hThread, INFINITE);
}

This one uses CreatedThread and exhausts all the heap memory before calling strtok — you get R6016 because the runtime cannot allocate memory for the per thread data.

Note that in both cases the executable must be linked statically to the VC runtime. __flsindex isn’t accessible if you’re using the dll runtime so the first approach fails to link. The dll runtime relies on DLL_THREAD_ATTACH notifications to allocate the
per thread data and it’s more likely that thread creation will simply fail than to get R6016.

Both situations are possible in practice but it seems to me that you’d have to be quite unlucky for the outcome of memory corruption or lack of memory to be this R6016 error.

PS: Anyone who wants to try the second example should run the release build and should not run it in the debugger. Doing otherwise might cause your system to lockup for some time due to excessive paging.

• Edited by
  Mike Danes
  Friday, January 17, 2014 10:03 AM
• Marked as answer by
  Jane Wang — MSFT
  Thursday, January 23, 2014 4:25 AM

Microsft actual has has creaated a bounds check by creatting a managed Net Library which has a hugh overhead to prevent these type errors.  Microsoft also has a C++ library for people who don’t want to use either C# or VBnet.  Using C++ you are
taking a risk that you end up with memory leaks exceptions and just have to roll up your sleeves and debug these issues.  I have solved lots of intermittents like this and know that it just a normal part of programming, and there isn’t a simple solution.

jdweng

• Marked as answer by
  Jane Wang — MSFT
  Thursday, January 23, 2014 4:24 AM

See also
kb118816 about possible reasons of TLS allocation failures,  although it also refers to win32s. IIRC, even if one believes that a VC++2012 app is linked statically, there are some DLLs involved in runtime, nevertheless.

To get the latest VC++ library,
look here.

— pa

• Edited by
  Pavel A
  Thursday, January 16, 2014 2:04 AM
• Marked as answer by
  Jane Wang — MSFT
  Thursday, January 23, 2014 4:23 AM