You can clone with
// Each log entry has the following syntax:
// + BYTES_DELTA (NEW_BYTES - OLD_BYTES) NEW_COUNT allocs BackTrace TRACEID
// + COUNT_DELTA (NEW_COUNT - OLD_COUNT) BackTrace TRACEID allocations
// ... stack trace ...
// BYTES_DELTA - increase in bytes between before and after log
// NEW_BYTES - bytes in after log
// OLD_BYTES - bytes in before log
// COUNT_DELTA - increase in allocations between before and after log
// NEW_COUNT - number of allocations in after log
// OLD_COUNT - number of allocations in before log
// TRACEID - decimal index of the stack trace in the trace database
// (can be used to search for allocation instances in the original
// UMDH logs).
70 ( 103 - 33) BackTraceCDB3E61D allocations
ntdll! ?? ::FNODOBFM::`string'+13C96
iisnode!CProtocolBridge::ProcessResponseBody+210 (f:\projects\iisnode\src\iisnode\cprotocolbridge.cpp, 1545)
iisnode!CAsyncManager::Worker+174 (f:\projects\iisnode\src\iisnode\casyncmanager.cpp, 172)
This was found using http://support.microsoft.com/kb/268343.
Using AllocateRequestMemory in the context of long running websockets leads to apparent memory leak since the memory is only released when the websocket connection is closed, which may be gigabytes since the connection was established.
fix #225: memory leak in websocket response processing