Thread overview
[ddbg] - Error after the process is terminated
Oct 09, 2007
Simen Haugen
Oct 09, 2007
Jascha Wetzel
Oct 10, 2007
Simen Haugen
Oct 16, 2007
Nicki Newby
Oct 17, 2007
Simen Haugen
Oct 17, 2007
Nicki Newby
Oct 17, 2007
Jascha Wetzel
October 09, 2007
I get this error when the debugger exists, and some breakpoints won't
work...
I'm also redirecting stdout in my program and writes to a file, but now
nothing gets written to disk. I was doing this before too, but then
everything worked, so I don't know if that could be the problem.


Ddbg 0.10 beta - D Debugger
Copyright (c) 2007 Jascha Wetzel
see http://ddbg.mainia.de/doc.html for documentation

Loading symbols from C:\projects\in2dummy\trunk\bin\debug\in2dummy.exe
->Breakpoint set: C:\projects\in2dummy\trunk\src\i2f.d:772 0x404b48 all
threads
->Expression evaluation depth is 1
->Starting debuggee in new console
->ntdll.dll loaded at 0x7c900000
KERNEL32.dll loaded at 0x7c800000
ODBC32.dll loaded at 0x74320000
msvcrt.dll loaded at 0x77c10000
COMCTL32.dll loaded at 0x5d090000
ADVAPI32.dll loaded at 0x77dd0000
RPCRT4.dll loaded at 0x77e70000
GDI32.dll loaded at 0x77f10000
USER32.dll loaded at 0x7e410000
SHELL32.dll loaded at 0x7c9c0000
SHLWAPI.dll loaded at 0x77f60000
comdlg32.dll loaded at 0x763b0000
IMM32.dll loaded at 0x76390000
GoogleDesktopNetwork3.DLL loaded at 0x48000000
WS2_32.dll loaded at 0x71ab0000
WS2HELP.dll loaded at 0x71aa0000
unknown DLL loaded
odbcjt32.dll loaded at 0x4dd40000
msjet40.dll loaded at 0x1b000000
mswstr10.dll loaded at 0x1b5d0000
ole32.dll loaded at 0x774e0000
OLEAUT32.dll loaded at 0x77120000
odbcji32.dll loaded at 0x5d130000
msjter40.dll loaded at 0x1b2c0000
MSJINT40.DLL loaded at 0x1b2d0000
ODBCCP32.dll loaded at 0x5fe80000
VERSION.dll loaded at 0x77c00000
Secur32.dll loaded at 0x77fe0000
MSRD2X40.dll loaded at 0x1b200000
CLBCatQ.DLL loaded at 0x76fd0000
COMRes.dll loaded at 0x77050000
CLBCatQ.DLL loaded at 0x76fd0000
COMRes.dll loaded at 0x77050000
MSJTES40.dll loaded at 0x1b810000
VBAJET32.dll loaded at 0x0f9a0000
EXPSRV.dll loaded at 0x0f9c0000
mswdat10.dll loaded at 0x1b670000
mswdat10.dll loaded at 0x1b670000
Process terminated
->OUTPUT DEBUG STRING:
SXS: Unable to resolve storage root for assembly directory
x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03
in 2 tries

OUTPUT DEBUG STRING:
SXS: RtlGetAssemblyStorageRoot() unable to resolve storage map entry.
Status = 0xc0150004




October 09, 2007
Simen Haugen wrote:
> I get this error when the debugger exists, and some breakpoints won't work...

can you give me what i need to reproduce the breakpoints that don't work?

> I'm also redirecting stdout in my program and writes to a file, but now nothing gets written to disk. I was doing this before too, but then everything worked, so I don't know if that could be the problem.

it worked before what?

> Process terminated
> ->OUTPUT DEBUG STRING:
> SXS: Unable to resolve storage root for assembly directory
> x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03
> in 2 tries
> 
> OUTPUT DEBUG STRING:
> SXS: RtlGetAssemblyStorageRoot() unable to resolve storage map entry.
> Status = 0xc0150004

these errors are output by the side-by-side assembly routines (SXS) via the output debug string interface. that is, some DLL sends a string to the debugger for display to the user (of the debugger). therefore they are application errors. the fact that they appear after the process termination has to be related to how these the win32 debugging facilities cooperate with the SXS.
October 10, 2007
"Jascha Wetzel" <firstname@mainia.de> wrote in message news:fego2f$1jov$1@digitalmars.com...
> Simen Haugen wrote:
>> I get this error when the debugger exists, and some breakpoints won't work...
>
> can you give me what i need to reproduce the breakpoints that don't work?

My bad, all breakpoints worked.


>> I'm also redirecting stdout in my program and writes to a file, but now nothing gets written to disk. I was doing this before too, but then everything worked, so I don't know if that could be the problem.
>
> it worked before what?

Thats what I don't know. The project is in the start phase, and I haven't added it to version control yet...


>> Process terminated
>> ->OUTPUT DEBUG STRING:
>> SXS: Unable to resolve storage root for assembly directory
>> x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03
>> in 2 tries
>>
>> OUTPUT DEBUG STRING:
>> SXS: RtlGetAssemblyStorageRoot() unable to resolve storage map entry.
>> Status = 0xc0150004
>
> these errors are output by the side-by-side assembly routines (SXS) via the output debug string interface. that is, some DLL sends a string to the debugger for display to the user (of the debugger). therefore they are application errors. the fact that they appear after the process termination has to be related to how these the win32 debugging facilities cooperate with the SXS.

Way over my head...


Sorry I couldn't help locating some more info.


October 16, 2007
Open the Run Dialog and create a new Environment Variable "SystemPath" with value "C:\Windows"  or, if you did not install windows to the default directory then wherever it is installed.
October 17, 2007
I mailed Jascha the code, and I think he has a fix for it already. Looking forward to 0.11

"Nicki Newby" <newby@niancrae.com> wrote in message news:ff39eo$2n9j$1@digitalmars.com...
> Open the Run Dialog and create a new Environment Variable "SystemPath"
> with value
> "C:\Windows"  or, if you did not install windows to the default directory
> then
> wherever it is installed.


October 17, 2007
If you or Jascha have a different fix, I'd appreciate hearing what it is.  I had to search on  non-D programming forums to figure this out.  It seems that the compiler is looking for comctl32.dll in the referenced directory.  There should be other ways of setting the SystemPath.  But this fix is easy and works.

Simen Haugen Wrote:

> I mailed Jascha the code, and I think he has a fix for it already. Looking forward to 0.11
> 

October 17, 2007
Nicki Newby wrote:
> If you or Jascha have a different fix, I'd appreciate hearing what it is.  I had to search on  non-D programming forums to figure this out.  It seems that the compiler is looking for comctl32.dll in the referenced directory.  There should be other ways of setting the SystemPath.  But this fix is easy and works.
> 
> Simen Haugen Wrote:
> 
>> I mailed Jascha the code, and I think he has a fix for it already.
>> Looking forward to 0.11

i think you are talking about two different issues.
my fix will be for the incorrect breakpoints, not the SXS issue.