Digital Mars - digitalmars.D.debugger - [ddbg] - Error after the process is terminated

↑ ↓ ← → "Simen Haugen" <simen norstat.no> writes:

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

Oct 09 2007

↑ ↓ ← → Jascha Wetzel <firstname mainia.de> writes:

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.

Oct 09 2007

↑ ↓ ← → "Simen Haugen" <simen norstat.no> writes:

"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.

Oct 09 2007

↑ ↓ ← → "Simen Haugen" <simen norstat.no> writes:

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.

Oct 17 2007

↑ ↓ ← → Nicki Newby <newby niancrae.com> writes:

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

Oct 17 2007

↑ ↓ ← → Jascha Wetzel <firstname mainia.de> writes:

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.

Oct 17 2007