Discussion:
werl R14A on windows 7 frequently crashes during file access
(too old to reply)
unknown
2010-07-15 16:39:03 UTC
Permalink
I'm not entirely sure what combination of running software is causing
this. I have a program that opens a list of log files (~100kb to
~200kb), reads one a line at a time, matches the line against some
regexes, prints a report and finishes). Sometimes it works without a
problem. But other times werl will crash one or two lines into reading
the first log file, or when it opens up the report file. I have my
.erl, .beam and final report file in a Dropbox directory, which may be
affecting it. But the log files I'm opening for read are in a normal
directory. None of the files are in use by another running program,
except the .erl is open in my editor.

Win7 gives me a report like this when it crashes:
Problem signature:
Problem Event Name: APPCRASH
Application Name: werl.exe
Application Version: 0.0.0.0
Application Timestamp: 4c17b8f1
Fault Module Name: beam.smp.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4c17b83a
Exception Code: c0000005
Exception Offset: 000cc562
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

The file open/close/read code is:
%% Iterarate over files and generate report
% initialize report accumulator
report(Files) -> report(Files, []).
report([], Reports) ->
case file:open("ErrorReport.txt", write) of
{ok, Dev} ->
io:format("Opened Report file for writing~n", []),
map(fun({FileName, Report}) -> print_report(Dev, FileName,
Report) end, lists:reverse(Reports)),
file:close(Dev);
{error, Reason} ->
io:format("Error opening final report file: ~p~n", [Reason]),
{error, Reason}
end;
report([FileName | Rest], Acc) ->
io:format("Attempting to open: ~p~n", [FileName]),
% read file into memory
case file:open(FileName, read) of
{ok, Dev} ->
% scan the lines for string matches, one line at a time
{ok, WarningExp} = re:compile("warning", [caseless]),
{ok, ErrorExp} = re:compile("error", [caseless]),

Compiled_Tests = [
{warnings, warning_exps(), WarningExp},
{errors, error_exps(), ErrorExp}],
Report = scan_lines(Compiled_Tests, Dev, io:get_line(Dev, '')),
% close file
file:close(Dev),
% recurse
report(Rest, [{FileName, Report} | Acc]);
{error, Reason} ->
report(Rest, [{error, Reason} | Acc])
end.

Not sure how I can prevent werl from crashing and figure out what's
going on. Has anyone else seen this?
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw

"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
unknown
2010-07-17 21:30:48 UTC
Permalink
Post by unknown
I'm not entirely sure what combination of running software is causing
this. I have a program that opens a list of log files (~100kb to
~200kb), reads one a line at a time, matches the line against some
regexes, prints a report and finishes). Sometimes it works without a
problem. But other times werl will crash one or two lines into reading
the first log file, or when it opens up the report file. I have my
.erl, .beam and final report file in a Dropbox directory, which may be
Hi Brian,

I don't expect Dropbox to be the problem but have you tested on
a Windows 7 install without Dropbox ever installed?
Post by unknown
Problem Event Name: APPCRASH
Application Name: werl.exe
Application Version: 0.0.0.0
Application Timestamp: 4c17b8f1
Fault Module Name: beam.smp.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4c17b83a
Exception Code: c0000005
Exception Offset: 000cc562
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
If you have a Windows crash dump for that I would make a backup of
the dump. Just in case...
Post by unknown
{ok, WarningExp} = re:compile("warning", [caseless]),
{ok, ErrorExp} = re:compile("error", [caseless]),
Compiled_Tests = [
{warnings, warning_exps(), WarningExp},
{errors, error_exps(), ErrorExp}],
Report = scan_lines(Compiled_Tests, Dev, io:get_line(Dev, '')),
What's the definition of scan_lines/3 (what does it do with
the result of io:get_line/2 and with the compiled patterns)?
unknown
2010-07-19 13:24:24 UTC
Permalink
Post by unknown
Post by unknown
I'm not entirely sure what combination of running software is causing
this. I have a program that opens a list of log files (~100kb to
~200kb), reads one a line at a time, matches the line against some
regexes, prints a report and finishes). Sometimes it works without a
problem. But other times werl will crash one or two lines into reading
the first log file, or when it opens up the report file. I have my
.erl, .beam and final report file in a Dropbox directory, which may be
Hi Brian,
I don't expect Dropbox to be the problem but have you tested on
a Windows 7 install without Dropbox ever installed?
I have run a bunch of other examples and my own code right off beams
in drop box before. Just none that have done file i/o, but I can move
these files elsewhere and try that, too.
Post by unknown
Post by unknown
Problem Event Name: ? APPCRASH
Application Name: ? ? werl.exe
Application Version: ?0.0.0.0
Application Timestamp: ? ? ? ?4c17b8f1
Fault Module Name: ? ?beam.smp.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: ? ? ? 4c17b83a
Exception Code: ? ? ? c0000005
Exception Offset: ? ? 000cc562
OS Version: ? 6.1.7600.2.0.0.256.48
Locale ID: ? ?1033
Additional Information 1: ? ? 0a9e
Additional Information 2: ? ? 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: ? ? 0a9e
Additional Information 4: ? ? 0a9e372d3b4ad19135b953a78882e789
If you have a Windows crash dump for that I would make a backup of
the dump. Just in case...
Where would I look for this dump? Would I be able to make sense of it at all?
Post by unknown
Post by unknown
? ? ? ? ? ?{ok, WarningExp} = re:compile("warning", [caseless]),
? ? ? ? ? ?{ok, ErrorExp} = re:compile("error", [caseless]),
? ? ? ? ? ?Compiled_Tests = [
? ? ? ? ? ? ? ?{warnings, warning_exps(), WarningExp},
? ? ? ? ? ? ? ?{errors, error_exps(), ErrorExp}],
? ? ? ? ? ?Report = scan_lines(Compiled_Tests, Dev, io:get_line(Dev, '')),
What's the definition of scan_lines/3 (what does it do with
the result of io:get_line/2 and with the compiled patterns)?
Here's the rest except for the report printing, which is pretty simple.

% starts an empty report for accumulation
scan_lines(Compiled_Tests, Dev, Line) ->
scan_lines(Compiled_Tests, Dev, Line,
[{warnings, []}, {errors, []}]).
% reached end of file, return report
scan_lines(_Compiled_Tests, _Dev, eof, Report) -> Report;
scan_lines(Compiled_Tests, Dev, Line, Report) ->
% match line and update report
% io:format("Attempting to match line: ~s~n", [Line]),
UpdatedReport = update_report(Compiled_Tests, Line, Report),
% get next line and recurse
scan_lines(Compiled_Tests, Dev, io:get_line(Dev, ''), UpdatedReport).

%% Takes a line, scans for errors and warnings and updates the report
update_report([], _Line, Report) -> Report;
update_report([{Group, Tests, GroupMatch} | Compiled_Tests], Line, Report) ->
case re:run(Line, GroupMatch) of
{match, _Captured} ->
% io:format("Matched ~p, checking for specific ~p
errors~n", [Group, Group]),
check_test(Line, Group, Tests, Report);
nomatch -> update_report(Compiled_Tests, Line, Report)
end.

check_test(Line, Group, [], Report) ->
io:format("Unmatched ~p for line: ~s", [Group, Line]),
increment_report(Report, {Group, unknown, "Non-matched line"});
check_test(Line, Group, [{TestName, Exp, Test} | RestTests], Report) ->
case re:run(Line, Exp) of
{match, _TestCapture} ->
% return new report, don't recurse
% io:format("Matched a test, incrementing: ~p~n", [TestName]),
increment_report(Report, {Group, TestName, Test});
nomatch ->
% try the next test
check_test(Line, Group, RestTests, Report)
end.

increment_report(Report, {Group, TestName, Test}) ->
% get the group of counts in the report that we're working with
{Group, Counts} = lists:keyfind(Group, 1, Report),
% io:format("Got counts: ~p for test group: ~p~n", [Counts, Group]),
case lists:keyfind(TestName, 1, Counts) of
% if that test is already in the report, increment
{TestName, CurrentCount, _MatchTest} ->
% io:format("Replacing count with ~p~n", [{TestName,
CurrentCount +1}]),
lists:keyreplace(Group, 1, Report, {Group,
lists:keyreplace(TestName, 1, Counts, {TestName,
CurrentCount + 1, Test})});
% else, add it in with initial count of 1
false ->
% io:format("Couldn't find test ~p in report, adding a new
one~n", [TestName]),
lists:keyreplace(Group, 1, Report, {Group, [{TestName, 1,
Test} | Counts]})
end.
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw

"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
unknown
2010-07-19 20:22:37 UTC
Permalink
Post by unknown
Where would I look for this dump?
Default should be C:\Windows\minidumps and I think it's configurable.
Post by unknown
Would I be able to make sense of it at all?
As you saw a crash dialog and no debugger was started it's safe
to assume that no postmortem debugger is configured.
Therefore a tool called DrWatson should have written a crashdump file.

You can use windbg to load the dump file and beam.smp.pdb to see
where it crashed. The PDB file contains debug info/symbols and you
should find it here: <ErlangInstallDir>\erts-5.8\bin\beam.smp.pdb.

If you don't have windbg installed, start here:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx

If you have never used windbg, continue here:
http://www.codeproject.com/KB/debug/windbg_part1.aspx#_Toc64133675

If you want to reproduce the crash and not search for the dump file,
consider configuring windbg as the portmortem debugger:
http://msdn.microsoft.com/en-us/library/ff539055%28v=VS.85%29.aspx
http://www.codeproject.com/KB/debug/windbg_part1.aspx#_Toc64133667
unknown
2010-07-20 12:26:55 UTC
Permalink
Post by unknown
Post by unknown
Where would I look for this dump?
Default should be C:\Windows\minidumps and I think it's configurable.
That directory doesn't exist. I guess I have to configure it in
Windows somewhere? I don't know where to do that.
Post by unknown
Post by unknown
Would I be able to make sense of it at all?
As you saw a crash dialog and no debugger was started it's safe
to assume that no postmortem debugger is configured.
Therefore a tool called DrWatson should have written a crashdump file.
You can use windbg to load the dump file and beam.smp.pdb to see
where it crashed. The PDB file contains debug info/symbols and you
should find it here: <ErlangInstallDir>\erts-5.8\bin\beam.smp.pdb.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
http://www.codeproject.com/KB/debug/windbg_part1.aspx#_Toc64133675
If you want to reproduce the crash and not search for the dump file,
http://msdn.microsoft.com/en-us/library/ff539055%28v=VS.85%29.aspx
http://www.codeproject.com/KB/debug/windbg_part1.aspx#_Toc64133667
I'll grab that and take a look, thanks!
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw

"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
unknown
2010-07-20 12:30:21 UTC
Permalink
Post by unknown
Post by unknown
Post by unknown
Where would I look for this dump?
Default should be C:\Windows\minidumps and I think it's configurable.
That directory doesn't exist. I guess I have to configure it in
Windows somewhere? I don't know where to do that.
What about C:\Windows\minidump?
unknown
2010-07-20 12:47:50 UTC
Permalink
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Where would I look for this dump?
Default should be C:\Windows\minidumps and I think it's configurable.
That directory doesn't exist. I guess I have to configure it in
Windows somewhere? I don't know where to do that.
What about C:\Windows\minidump?
No. I should probably add that this is a windows 7 box. Is that
location determined by the OS when it detects the crash, or by werl
before it dies?
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw

"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
unknown
2010-07-20 13:03:56 UTC
Permalink
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Where would I look for this dump?
Default should be C:\Windows\minidumps and I think it's configurable.
That directory doesn't exist. I guess I have to configure it in
Windows somewhere? I don't know where to do that.
What about C:\Windows\minidump?
No. I should probably add that this is a windows 7 box. Is that
location determined by the OS when it detects the crash, or by werl
before it dies?
It is determined by the crash handler configured in the OS settings
and possible that no crash dump has been written or that it's in a
different directory. I don't have a Windows install to check. You
might want to read the docs about configuring user-mode minidumps and
enabling crash dumps. Have a look in the MSDN.

You can also install windbg as the postmortem debugger and have it
spawned on each unhandled crash if you don't want to configure crash
dump settings. Also some applications like popular web browsers have
their own crash handler to collect and submit crash info to their
online database. These may not trigger a system level debugger at all
if their crash handler is not disabled.
unknown
2010-07-20 17:24:56 UTC
Permalink
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Where would I look for this dump?
Default should be C:\Windows\minidumps and I think it's configurable.
That directory doesn't exist. I guess I have to configure it in
Windows somewhere? I don't know where to do that.
What about C:\Windows\minidump?
No. I should probably add that this is a windows 7 box. Is that
location determined by the OS when it detects the crash, or by werl
before it dies?
It is determined by the crash handler configured in the OS settings
and possible that no crash dump has been written or that it's in a
different directory. I don't have a Windows install to check. You
might want to read the docs about configuring user-mode minidumps and
enabling crash dumps. Have a look in the MSDN.
You can also install windbg as the postmortem debugger and have it
spawned on each unhandled crash if you don't want to configure crash
dump settings. Also some applications like popular web browsers have
their own crash handler to collect and submit crash info to their
online database. These may not trigger a system level debugger at all
if their crash handler is not disabled.
Looks like in windows 7, after turning mini dumps on in advanced
settings, they go to:

C:\Users\<username>\AppData\Local\CrashDumps
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw

"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
unknown
2010-07-23 13:42:31 UTC
Permalink
Interesting stuff from windbg on the crash dump:
Symbol search path is: C:\Program
Files\erl5.8\erts-5.8\bin;SRV*c:*http://msdl.microsoft.com/download/symbols

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(3760.2d8c): Access violation - code c0000005 (first/second chance not
available)
eax=00000000 ebx=01b6f544 ecx=00000400 edx=00000000 esi=00000002 edi=00000000
eip=76fc64f4 esp=01b6f4f4 ebp=01b6f590 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!KiFastSystemCallRet:
76fc64f4 c3 ret
0:001> .ecxr
eax=00000000 ebx=00000000 ecx=015a8830 edx=00000000 esi=00000074 edi=015a2632
eip=0139c562 esp=01b6fb40 ebp=001a081c iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010293
beam_smp!ConDrawText+0x92:
0139c562 66893442 mov word ptr [edx+eax*2],si ds:0023:00000000=????
0:001> .lastevent
Last event: 3760.2d8c: Access violation - code c0000005 (first/second
chance not available)
debugger time: Fri Jul 23 09:16:53.209 2010 (UTC - 4:00)

I cannot set windbg as the post mortem as apparently I don't have the
proper permissions on this work box.
I still don't think I'm loading the symbols for the werl specific
stuff correctly.
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Post by unknown
Where would I look for this dump?
Default should be C:\Windows\minidumps and I think it's configurable.
That directory doesn't exist. I guess I have to configure it in
Windows somewhere? I don't know where to do that.
What about C:\Windows\minidump?
No. I should probably add that this is a windows 7 box. Is that
location determined by the OS when it detects the crash, or by werl
before it dies?
It is determined by the crash handler configured in the OS settings
and possible that no crash dump has been written or that it's in a
different directory. I don't have a Windows install to check. You
might want to read the docs about configuring user-mode minidumps and
enabling crash dumps. Have a look in the MSDN.
You can also install windbg as the postmortem debugger and have it
spawned on each unhandled crash if you don't want to configure crash
dump settings. Also some applications like popular web browsers have
their own crash handler to collect and submit crash info to their
online database. These may not trigger a system level debugger at all
if their crash handler is not disabled.
Looks like in windows 7, after turning mini dumps on in advanced
C:\Users\<username>\AppData\Local\CrashDumps
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw
"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw

"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
unknown
2010-07-23 23:43:13 UTC
Permalink
Post by unknown
Symbol search path is: C:\Program
Files\erl5.8\erts-5.8\bin;SRV*c:*http://msdl.microsoft.com/download/symbols
[...]
Post by unknown
0139c562 66893442 ? ? ? ?mov ? ? word ptr [edx+eax*2],si ?ds:0023:00000000=????
0:001> .lastevent
Does it also crash if you use erl.exe instead of werl.exe?
unknown
2010-07-23 23:58:29 UTC
Permalink
call stacks of the three crash dumps:

werl.exe.9504.dmp

ChildEBP RetAddr Args to Child
01a2d6ec 76fc5e4c 75386872 00000002 01a2d740 ntdll!KiFastSystemCallRet
01a2d6f0 75386872 00000002 01a2d740 00000001 ntdll!NtWaitForMultipleObjects+0xc
01a2d78c 759ef14a 01a2d740 01a2d7b4 00000000
KERNELBASE!WaitForMultipleObjectsEx+0x100
01a2d7d4 759ef2c2 00000002 7ffd4000 00000000
kernel32!WaitForMultipleObjectsExImplementation+0xe0
01a2d7f0 75a02f1d 00000002 01a2d824 00000000
kernel32!WaitForMultipleObjects+0x18
01a2d85c 75a02fba 01a2d93c 00000001 00000001
kernel32!WerpReportFaultInternal+0x186
01a2d870 75a02d48 01a2d93c 00000001 01a2d90c kernel32!WerpReportFault+0x70
01a2d880 75a02cc7 01a2d93c 00000001 4ba91c66 kernel32!BasepReportFault+0x20
01a2d90c 76ff5a74 00000000 76f9d950 00000000
kernel32!UnhandledExceptionFilter+0x1af
01a2d914 76f9d950 00000000 01a2ffd4 76fd0598 ntdll!__RtlUserThreadStart+0x62
01a2d928 76f9d7ec 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12
01a2d950 76fc65f9 fffffffe 01a2ffc4 01a2da58 ntdll!_except_handler4+0x8e
01a2d974 76fc65cb 01a2da3c 01a2ffc4 01a2da58 ntdll!ExecuteHandler2+0x26
01a2da24 76fc6457 00a2da3c 01a2da58 01a2da3c ntdll!ExecuteHandler+0x24
01a2da24 76fd1ffe 00a2da3c 01a2da58 01a2da3c ntdll!KiUserExceptionDispatcher+0xf
01a2dd70 76fd1faf 0180dee0 01830c98 01830858 ntdll!RtlpLowFragHeapFree+0x31
01a2dd88 759ef1cc 002f0000 00000000 0180dee0 ntdll!RtlFreeHeap+0x105
01a2dd9c 70ff4c39 002f0000 00000000 0180dee0 kernel32!HeapFree+0x14
01a2dde8 011ed4fc 0180dee0 009a0b24 0000028c msvcr80!free+0xcd
01a2de0c 011ed67d 009a0b24 01a2defc 00000005
beam_smp!reorganize_linebufs(struct HWND__ * hwnd = <Memory access
error>)+0x22c
01a2de6c 011ed7f1 009a0b24 00000000 0000029d
beam_smp!Client_OnSize(struct HWND__ * hwnd = 0x755d8876, unsigned int
state = 0x11ed7a0, int cx = 0n10095396, int cy = 0n5)+0xbd
01a2de80 755d86ef 009a0b24 00000005 00000000
beam_smp!ClientWndProc(struct HWND__ * hwnd = 0x755d8876, unsigned int
iMsg = 0x11ed7a0, unsigned int wParam = 0x9a0b24, long lParam =
0n5)+0x51
01a2deac 755d8876 011ed7a0 009a0b24 00000005 user32!InternalCallWinProc+0x23
01a2df24 755d1945 00000000 011ed7a0 009a0b24
user32!UserCallWinProcCheckWow+0x14b
01a2dfac 755d7308 009a0b24 011ed7a0 009a0b24
user32!RealDefWindowProcWorker+0x50c
01a2dfc8 73d81e60 009a0b24 00000047 00000000 user32!RealDefWindowProcW+0x47
01a2e024 73d81f20 00000000 00000000 00000000 uxtheme!_ThemeDefWindowProc+0x197
01a2e040 755d79f0 009a0b24 00000047 00000000 uxtheme!ThemeDefWindowProcW+0x18
01a2e088 755d86ef 009a0b24 00000047 00000000 user32!DefWindowProcW+0x68
01a2e0b4 755d79cc 011ed7a0 009a0b24 00000047 user32!InternalCallWinProc+0x23
01a2e12c 755d70f4 00000000 011ed7a0 009a0b24 user32!UserCallWinProcCheckWow+0xe0
01a2e188 755d184e 00596f80 00000047 00000000 user32!DispatchClientMessage+0xda
01a2e1b0 76fc642e 01a2e1c8 00000030 01a2e27c user32!__fnINLPWINDOWPOS+0x25
01a2e1f4 755d66ca 73d8cb9d 009a0b24 00000000 ntdll!KiUserCallbackDispatcher+0x2e
01a2e1f8 73d8cb9d 009a0b24 00000000 01a2e2a8 user32!NtUserSetScrollInfo+0xc
01a2e244 755d6672 009a0b24 00000000 01a2e2a8 uxtheme!ThemeSetScrollInfoProc+0x70
01a2e28c 011eaaff 009a0b24 00000000 01a2e2a8 user32!SetScrollInfo+0x57
01a2e2c0 011ed5e2 01a2e3ac 00000005 00000000
beam_smp!set_scroll_info(struct HWND__ * hwnd = 0x0180ded8)+0xaf
01a2e31c 011ed7f1 009a0b24 00000000 0000029d
beam_smp!Client_OnSize(struct HWND__ * hwnd = 0x755d8876, unsigned int
state = 0x11ed7a0, int cx = 0n10095396, int cy = 0n5)+0x22
01a2e330 755d86ef 009a0b24 00000005 00000000
beam_smp!ClientWndProc(struct HWND__ * hwnd = 0x755d8876, unsigned int
iMsg = 0x11ed7a0, unsigned int wParam = 0x9a0b24, long lParam =
0n5)+0x51
01a2e35c 755d8876 011ed7a0 009a0b24 00000005 user32!InternalCallWinProc+0x23
01a2e3d4 755d1945 00000000 011ed7a0 009a0b24
user32!UserCallWinProcCheckWow+0x14b
01a2e45c 755d7308 009a0b24 011ed7a0 009a0b24
user32!RealDefWindowProcWorker+0x50c
01a2e478 73d81e60 009a0b24 00000047 00000000 user32!RealDefWindowProcW+0x47
01a2e4d4 73d81f20 00000000 00000000 00000000 uxtheme!_ThemeDefWindowProc+0x197
01a2e4f0 755d79f0 009a0b24 00000047 00000000 uxtheme!ThemeDefWindowProcW+0x18
01a2e538 755d86ef 009a0b24 00000047 00000000 user32!DefWindowProcW+0x68
01a2e564 755d79cc 011ed7a0 009a0b24 00000047 user32!InternalCallWinProc+0x23
01a2e5dc 755d70f4 00000000 011ed7a0 009a0b24 user32!UserCallWinProcCheckWow+0xe0
01a2e638 755d184e 00596f80 00000047 00000000 user32!DispatchClientMessage+0xda
01a2e660 76fc642e 01a2e678 00000030 01a2ea84 user32!__fnINLPWINDOWPOS+0x25
01a2e6a4 755ca8d0 011ecab3 009a0b24 00000000 ntdll!KiUserCallbackDispatcher+0x2e
01a2e6a8 011ecab3 009a0b24 00000000 0000001c user32!NtUserMoveWindow+0xc
01a2e9f0 755d86ef 000807d2 00000005 00000000
beam_smp!FrameWndProc(struct HWND__ * hwnd = <Memory access error>,
unsigned int iMsg = <Memory access error>, unsigned int wParam =
<Memory access error>, long lParam = <Memory access error>)+0x133
01a2ea1c 755d8876 011ec980 000807d2 00000005 user32!InternalCallWinProc+0x23
01a2ea94 755d1945 00000000 011ec980 000807d2
user32!UserCallWinProcCheckWow+0x14b
01a2eb1c 755d7308 011ec980 011ec980 000807d2
user32!RealDefWindowProcWorker+0x50c
01a2eb38 73d81e60 000807d2 00000047 00000000 user32!RealDefWindowProcW+0x47
01a2eb94 73d81f20 00000000 00000000 00000000 uxtheme!_ThemeDefWindowProc+0x197
01a2ebb0 755d79f0 000807d2 00000047 00000000 uxtheme!ThemeDefWindowProcW+0x18

werl.exe.12616.dmp

ChildEBP RetAddr Args to Child
01adf310 76fc5e4c 75386872 00000002 01adf364 ntdll!KiFastSystemCallRet
01adf314 75386872 00000002 01adf364 00000001 ntdll!NtWaitForMultipleObjects+0xc
01adf3b0 759ef14a 01adf364 01adf3d8 00000000
KERNELBASE!WaitForMultipleObjectsEx+0x100
01adf3f8 759ef2c2 00000002 7ffdd000 00000000
kernel32!WaitForMultipleObjectsExImplementation+0xe0
01adf414 75a02f1d 00000002 01adf448 00000000
kernel32!WaitForMultipleObjects+0x18
01adf480 75a02fba 01adf560 00000001 00000001
kernel32!WerpReportFaultInternal+0x186
01adf494 75a02d48 01adf560 00000001 01adf530 kernel32!WerpReportFault+0x70
01adf4a4 75a02cc7 01adf560 00000001 437b60c2 kernel32!BasepReportFault+0x20
01adf530 76ff5a74 00000000 76f9d950 00000000
kernel32!UnhandledExceptionFilter+0x1af
01adf538 76f9d950 00000000 01adffd4 76fd0598 ntdll!__RtlUserThreadStart+0x62
01adf54c 76f9d7ec 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12
01adf574 76fc65f9 fffffffe 01adffc4 01adf67c ntdll!_except_handler4+0x8e
01adf598 76fc65cb 01adf660 01adffc4 01adf67c ntdll!ExecuteHandler2+0x26
01adf648 76fc6457 00adf660 01adf67c 01adf660 ntdll!ExecuteHandler+0x24
01adf648 76f9f23e 00adf660 01adf67c 01adf660 ntdll!KiUserExceptionDispatcher+0xf
01adf98c 77007e3f 01887f00 01887f00 00000020 ntdll!RtlpDeCommitFreeBlock+0x146
01adfa74 76fd34ca 000000a2 000000b0 01887f02 ntdll!RtlpAllocateHeap+0x76b
01adfaf8 70ff4d83 006e0000 00000000 000000a2 ntdll!RtlAllocateHeap+0x23a
01adfb18 013bab33 000000a2 015c252a 755d7041 msvcr80!malloc+0x7a
01adfb28 013bc020 015c252a 013bc04f 013bc60d beam_smp!ConNewLine(void)+0x23
01adfb30 013bc04f 013bc60d 00000000 01adfbfc
beam_smp!ensure_line_below(void)+0x50
01adfb34 013bc60d 00000000 01adfbfc 00000401
beam_smp!ConCarriageFeed(int hard_newline = <Memory access error>)+0xf
01adfb78 013bd980 007c0eac 755d86ef 007c0eac
beam_smp!ConDrawText(struct HWND__ * hwnd = <Memory access
error>)+0x13d
01adfb80 755d86ef 007c0eac 00000401 00000000
beam_smp!ClientWndProc(struct HWND__ * hwnd = 0x755d8876, unsigned int
iMsg = 0x13bd7a0, unsigned int wParam = 0x7c0eac, long lParam =
0n1025)+0x1e0
01adfbac 755d8876 013bd7a0 007c0eac 00000401 user32!InternalCallWinProc+0x23
01adfc24 755d89b5 00000000 013bd7a0 007c0eac
user32!UserCallWinProcCheckWow+0x14b
01adfc84 755d8e9c 013bd7a0 00000000 00000000 user32!DispatchMessageWorker+0x35e
01adfc94 013bdc7d 01adfce4 00000000 00000000 user32!DispatchMessageW+0xf
01adff48 70ff29bb 00000000 43789f36 00000000
beam_smp!ConThreadInit(void * param = <Memory access error>)+0x2ed
01adff80 70ff2a47 00000000 759f1194 006e5258 msvcr80!_endthreadex+0x3b

werl.exe.14176.dmp

ChildEBP RetAddr Args to Child
01b6f4f0 76fc5e4c 75386872 00000002 01b6f544 ntdll!KiFastSystemCallRet
01b6f4f4 75386872 00000002 01b6f544 00000001 ntdll!NtWaitForMultipleObjects+0xc
01b6f590 759ef14a 01b6f544 01b6f5b8 00000000
KERNELBASE!WaitForMultipleObjectsEx+0x100
01b6f5d8 759ef2c2 00000002 7ffdf000 00000000
kernel32!WaitForMultipleObjectsExImplementation+0xe0
01b6f5f4 75a02f1d 00000002 01b6f628 00000000
kernel32!WaitForMultipleObjects+0x18
01b6f660 75a02fba 01b6f740 00000001 00000001
kernel32!WerpReportFaultInternal+0x186
01b6f674 75a02d48 01b6f740 00000001 01b6f710 kernel32!WerpReportFault+0x70
01b6f684 75a02cc7 01b6f740 00000001 b1896c2b kernel32!BasepReportFault+0x20
01b6f710 76ff5a74 00000000 76f9d950 00000000
kernel32!UnhandledExceptionFilter+0x1af
01b6f718 76f9d950 00000000 01b6ffd4 76fd0598 ntdll!__RtlUserThreadStart+0x62
01b6f72c 76f9d7ec 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12
01b6f754 76fc65f9 fffffffe 01b6ffc4 01b6f85c ntdll!_except_handler4+0x8e
01b6f778 76fc65cb 01b6f840 01b6ffc4 01b6f85c ntdll!ExecuteHandler2+0x26
01b6f828 76fc6457 00b6f840 01b6f85c 01b6f840 ntdll!ExecuteHandler+0x24
01b6f828 0139c562 00b6f840 01b6f85c 01b6f840 ntdll!KiUserExceptionDispatcher+0xf
01b6fb78 0139d980 001a081c 755d86ef 001a081c
beam_smp!ConDrawText(struct HWND__ * hwnd = <Memory access
error>)+0x92
01b6fb80 755d86ef 001a081c 00000401 00000000
beam_smp!ClientWndProc(struct HWND__ * hwnd = 0x755d8876, unsigned int
iMsg = 0x139d7a0, unsigned int wParam = 0x1a081c, long lParam =
0n1025)+0x1e0
01b6fbac 755d8876 0139d7a0 001a081c 00000401 user32!InternalCallWinProc+0x23
01b6fc24 755d89b5 00000000 0139d7a0 001a081c
user32!UserCallWinProcCheckWow+0x14b
01b6fc84 755d8e9c 0139d7a0 00000000 00000000 user32!DispatchMessageWorker+0x35e
01b6fc94 0139dc7d 01b6fce4 00000000 00000000 user32!DispatchMessageW+0xf
01b6ff48 70ff29bb 00000000 b189c442 00000000
beam_smp!ConThreadInit(void * param = <Memory access error>)+0x2ed
01b6ff80 70ff2a47 00000000 759f1194 005b5258 msvcr80!_endthreadex+0x3b
01b6ff88 759f1194 005b5258 01b6ffd4 76fdb3f5 msvcr80!_endthreadex+0xc7
01b6ff94 76fdb3f5 005b5258 5e587bd5 00000000 kernel32!BaseThreadInitThunk+0xe
01b6ffd4 76fdb3c8 70ff29e1 005b5258 00000000 ntdll!__RtlUserThreadStart+0x70
01b6ffec 00000000 70ff29e1 005b5258 00000000 ntdll!_RtlUserThreadStart+0x1b
unknown
2010-07-26 13:37:03 UTC
Permalink
Haven't tried the command line, good suggestion.
Post by unknown
Post by unknown
Symbol search path is: C:\Program
Files\erl5.8\erts-5.8\bin;SRV*c:*http://msdl.microsoft.com/download/symbols
[...]
Post by unknown
0139c562 66893442 ? ? ? ?mov ? ? word ptr [edx+eax*2],si ?ds:0023:00000000=????
0:001> .lastevent
Does it also crash if you use erl.exe instead of werl.exe?
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw

"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
unknown
2010-07-26 14:27:02 UTC
Permalink
Works perfectly from a command line shell. It may have to do with
rapidly spitting output to the werl GUI.
Post by unknown
Haven't tried the command line, good suggestion.
Post by unknown
Post by unknown
Symbol search path is: C:\Program
Files\erl5.8\erts-5.8\bin;SRV*c:*http://msdl.microsoft.com/download/symbols
[...]
Post by unknown
0139c562 66893442 ? ? ? ?mov ? ? word ptr [edx+eax*2],si ?ds:0023:00000000=????
0:001> .lastevent
Does it also crash if you use erl.exe instead of werl.exe?
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw
"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
--
Brian E. Williams
mixolyde
http://www.techhouse.us/wordpress-mu/brianw

"Never attribute to malice that which can be adequately
explained by stupidity." - Hanlon's Razor
Loading...