I've just installed CVF 6.6 on my windows xp.
Now I don't have problems that I found by Vista.
Now it compiles, builds and runs as it should.
Anyway I tried to debug a my code and I get this error:

Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic
information found.

Besides a pop-up window writes 'One o more breakpoints are not
positioned on valid lines. These break points have been moved to the
next valid line'

I understand the pop-up windows, but the previous errors?
I premise I didn't install Microsoft Visual Studio on my machine.

Allamarein wrote:
> I've just installed CVF 6.6 on my windows xp.
> Now I don't have problems that I found by Vista.
> Now it compiles, builds and runs as it should.
> Anyway I tried to debug a my code and I get this error:
> 
> Loaded 'ntdll.dll', no matching symbolic information found.
> Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic
> information found.
> 
> Besides a pop-up window writes 'One o more breakpoints are not
> positioned on valid lines. These break points have been moved to the
> next valid line'
> 
> I understand the pop-up windows, but the previous errors?
> I premise I didn't install Microsoft Visual Studio on my machine.

Sounds like you broke in the OS dll which isn't compiled w/ debug 
information.  CVF is simply telling you that.

W/ no user code one can only presume and what comes to me is one of two 
things -- either you're trying to use a Win API or one of the 
compatibility routines and there's a problem in the call sequence or 
there is still an issue w/ the installation.

Oh, I don't know if it's likely could be the cause of the symptom but I 
wonder if one tried linking a combination of built for console and 
windowed object files or similar if the startup code might be confused 
and end up in debugging mode that way...

Undoubtedly there are other things that could be causes but those are 
what strike me at the moment.

If it's a console app, I'd first simply start it w/o the debugger and 
see what symptoms are shown; that might be quite informative.

If not, I'd do a careful check for consistency within the project 
settings, etc. as noted above.

Since it seems that you have been successful in building at least some 
sample code/executable I'd tend to presume there's a fault in this one 
over the installation but there's a case that w/o anything at all to 
look at there's nothing to say but "Houston, we have a problem..."

--

On 18 Lug, 15:52, dpb <n...@non.net> wrote:
> Allamarein wrote:
> > I've just installed CVF 6.6 on my windows xp.
> > Now I don't have problems that I found by Vista.
> > Now it compiles, builds and runs as it should.
> > Anyway I tried to debug a my code and I get this error:
>
> > Loaded 'ntdll.dll', no matching symbolic information found.
> > Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic
> > information found.
>
> > Besides a pop-up window writes 'One o more breakpoints are not
> > positioned on valid lines. These break points have been moved to the
> > next valid line'
>
> > I understand the pop-up windows, but the previous errors?
> > I premise I didn't install Microsoft Visual Studio on my machine.
>
> Sounds like you broke in the OS dll which isn't compiled w/ debug
> information. =A0CVF is simply telling you that.
>
> W/ no user code one can only presume and what comes to me is one of two
> things -- either you're trying to use a Win API or one of the
> compatibility routines and there's a problem in the call sequence or
> there is still an issue w/ the installation.
>
> Oh, I don't know if it's likely could be the cause of the symptom but I
> wonder if one tried linking a combination of built for console and
> windowed object files or similar if the startup code might be confused
> and end up in debugging mode that way...
>
> Undoubtedly there are other things that could be causes but those are
> what strike me at the moment.
>
> If it's a console app, I'd first simply start it w/o the debugger and
> see what symptoms are shown; that might be quite informative.
>
> If not, I'd do a careful check for consistency within the project
> settings, etc. as noted above.
>
> Since it seems that you have been successful in building at least some
> sample code/executable I'd tend to presume there's a fault in this one
> over the installation but there's a case that w/o anything at all to
> look at there's nothing to say but "Houston, we have a problem..."
>
> --

Yeah, I think the problem it is the debugger, because my code work
greatly in release mode.
Installing Visual Studio can help?

Allamarein wrote:
....

> Yeah, I think the problem it is the debugger, because my code work
> greatly in release mode.
> Installing Visual Studio can help?

If the code doesn't fail w/o the debugger but is stopping when built w/ 
debugging I'd guess you have a breakpoint set or are starting w/ "step" 
or "step into" instead of "run" that's causing the debug window to open.

I have CVF 6.6 but use the interactive debugger so little I can't otomh 
tell you where or how specifically to clear all breakpoints w/o 
searching myself, but I'm quite confident it can be done.

I don't suspect there's anything about VS you need to do; only figure 
out how to use the debugger itself in the IDE.

--

dpb wrote:
> Allamarein wrote:
> ...
> 
>> Yeah, I think the problem it is the debugger, because my code work
>> greatly in release mode.
>> Installing Visual Studio can help?
> 
> If the code doesn't fail w/o the debugger but is stopping when built w/ 
> debugging I'd guess you have a breakpoint set or are starting w/ "step" 
> or "step into" instead of "run" that's causing the debug window to open.
....

As a followup to the above, note the following in the Debugger Help...

> Step Into Single-steps through instructions in the program, and 
> enters each function (or subroutine) call that is encountered. With 
> Visual Fortran programs, avoid using this menu command for initial
> program execution. Instead, set a breakpoint or insertion point at
> the first executable line of Fortran source code and either use Go or
> Run to Cursor. This avoids entering the Visual Fortran run-time 
> initialization code that is executed before your main Fortran routine

I'm virtually certain it's this you're seeing given the symptom description.

--

On 18 Lug, 21:05, dpb <n...@non.net> wrote:
> dpb wrote:
> > Allamarein wrote:
> > ...
>
> >> Yeah, I think the problem it is the debugger, because my code work
> >> greatly in release mode.
> >> Installing Visual Studio can help?
>
> > If the code doesn't fail w/o the debugger but is stopping when built w/
> > debugging I'd guess you have a breakpoint set or are starting w/ "step"
> > or "step into" instead of "run" that's causing the debug window to open.
>
> ...
>
> As a followup to the above, note the following in the Debugger Help...
>
> > Step Into Single-steps through instructions in the program, and
> > enters each function (or subroutine) call that is encountered. With
> > Visual Fortran programs, avoid using this menu command for initial
> > program execution. Instead, set a breakpoint or insertion point at
> > the first executable line of Fortran source code and either use Go or
> > Run to Cursor. This avoids entering the Visual Fortran run-time
> > initialization code that is executed before your main Fortran routine
>
> I'm virtually certain it's this you're seeing given the symptom description.
>
> --

Maybe better...
I open all *.for I need.
Then I build.
CVF suggests to create a standard workspace and project and it does
it, naming them as it prefers.
I attach every file I need in that project.
Build that and I debug: now it works!
However I would change the name of the workspace and of the project.
It is possible rename and changing path of workspace and projects,
after I created that?

Allamarein wrote:
> I've just installed CVF 6.6 on my windows xp.
> Now I don't have problems that I found by Vista.
> Now it compiles, builds and runs as it should.
> Anyway I tried to debug a my code and I get this error:
>
The Intel Fortran forum is the right place for this sort of question.  There are 
many knowledgeable and helpful people there.

Allamarein wrote:
....

> CVF suggests to create a standard workspace and project and it does
> it, naming them as it prefers.
> I attach every file I need in that project.
> Build that and I debug: now it works!
> However I would change the name of the workspace and of the project.
> It is possible rename and changing path of workspace and projects,
> after I created that?

Oh, I'm sure you probably could; however I'd simply create a new 
project, naming it as desired and put the files where you want and add 
them to the new project as you did to the default.  No big deal.

--

On 18 Lug, 23:59, dpb <n...@non.net> wrote:
> Allamarein wrote:
>
> ...
>
> > CVF suggests to create a standard workspace and project and it does
> > it, naming them as it prefers.
> > I attach every file I need in that project.
> > Build that and I debug: now it works!
> > However I would change the name of the workspace and of the project.
> > It is possible rename and changing path of workspace and projects,
> > after I created that?
>
> Oh, I'm sure you probably could; however I'd simply create a new
> project, naming it as desired and put the files where you want and add
> them to the new project as you did to the default. =A0No big deal.
>
> --

Quote:
Oh, I'm sure you probably could; however I'd simply create a new
project, naming it as desired and put the files where you want and
add
them to the new project as you did to the default.  No big deal.

In this way it crashes when I try to debug.
That is:
I open a blank workspace and a project.
I attach my *.f files.
In this way it crashes when I try to debug.
Maybe I choose the wrong project.

Instead if I follow the procedure I wrote in my last post, no
troubles...
Anyway CVF offers different projects.
Maybe I choose the wrong project....
I need a standard project (in this way CVF calls project it suggests
an automatic procedure), but I don't know how to choose that in manual
procedure.
Manual procdure will be:
I create a 'Blank Workspace'
I choose 'Fortran Windows application'.
Then I choose 'An empty Windows Application' and I dont'use 'this
project will be linking against one or more Fprtran DLL import
libraries'.
I attach my *.for files.
How I wrote, in this way debug doesn't work

Allamarein wrote:
....

> In this way it crashes when I try to debug.
> That is:
> I open a blank workspace and a project.
> I attach my *.f files.
> In this way it crashes when I try to debug.
> Maybe I choose the wrong project.
> 
> Instead if I follow the procedure I wrote in my last post, no
> troubles...
> Anyway CVF offers different projects.
> Maybe I choose the wrong project....
> I need a standard project (in this way CVF calls project it suggests
> an automatic procedure), but I don't know how to choose that in manual
> procedure.
> Manual procdure will be:
> I create a 'Blank Workspace'
> I choose 'Fortran Windows application'.
> Then I choose 'An empty Windows Application' and I dont'use 'this
> project will be linking against one or more Fprtran DLL import
> libraries'.
> I attach my *.for files.
> How I wrote, in this way debug doesn't work

Well, you need to know whether you're building a Windows app or 
not...I'm assuming you probably are building a console application 
rather than Windows; if it is a Windows app there has to be a Windwoes 
message processing loop and the proper initialization.  A console app, 
otoh, is what I would presume you mean by "standard project"--it'll be a 
straightforward Fortran program and its associated subroutines and 
functions.

There are sample projects of each type in the CVF installation--look at 
them and see for certain what your project resembles--I'm betting it is 
_NOT_ a Windows application.

--

On 19 Lug, 01:52, dpb <n...@non.net> wrote:
> Allamarein wrote:
>
> ...
>
>
>
>
>
> > In this way it crashes when I try to debug.
> > That is:
> > I open a blank workspace and a project.
> > I attach my *.f files.
> > In this way it crashes when I try to debug.
> > Maybe I choose the wrong project.
>
> > Instead if I follow the procedure I wrote in my last post, no
> > troubles...
> > Anyway CVF offers different projects.
> > Maybe I choose the wrong project....
> > I need a standard project (in this way CVF calls project it suggests
> > an automatic procedure), but I don't know how to choose that in manual
> > procedure.
> > Manual procdure will be:
> > I create a 'Blank Workspace'
> > I choose 'Fortran Windows application'.
> > Then I choose 'An empty Windows Application' and I dont'use 'this
> > project will be linking against one or more Fprtran DLL import
> > libraries'.
> > I attach my *.for files.
> > How I wrote, in this way debug doesn't work
>
> Well, you need to know whether you're building a Windows app or
> not...I'm assuming you probably are building a console application
> rather than Windows; if it is a Windows app there has to be a Windwoes
> message processing loop and the proper initialization. =A0A console app,
> otoh, is what I would presume you mean by "standard project"--it'll be a
> straightforward Fortran program and its associated subroutines and
> functions.
>
> There are sample projects of each type in the CVF installation--look at
> them and see for certain what your project resembles--I'm betting it is
> _NOT_ a Windows application.
>
> --

I try a 'console application'.
This is my code tester:
c	Debbuger test
	PROGRAM tester
	INTEGER i
	REAl(8) a
	DIMENSION b(3)
c
	WRITE(*,*) 'Insert a number'
	READ(*,*) a
c
	b=3D1.d0
	DO i=3D1,3
		b(i) =3D a**i
	ENDDO
c
	END
CVF build my code.
I launch the debug.
I insert '5'.
My debus doesn't go on and I get This output:
Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\shimeng.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\AppPatch\AcLayers.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\gdi32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\advapi32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\rpcrt4.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\secur32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\shell32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\msvcrt.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\shlwapi.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\ole32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\userenv.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\winspool.drv', no matching symbolic
information found.
Loaded 'C:\WINDOWS\AppPatch\AcGenral.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\winmm.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\oleaut32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\msacm32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\version.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\uxtheme.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\system32\imm32.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-
Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll',
no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\comctl32.dll', no matching symbolic
information found.
The thread 0xF0 has exited with code 0 (0x0).
The program 'C:\FORTRAN\sandorn\Debug\sandorn.exe' has exited with
code 0 (0x0).

Allamarein wrote:
> On 19 Lug, 01:52, dpb <n...@non.net> wrote:
>> Allamarein wrote:
....

> I try a 'console application'.
> This is my code tester:
> c	Debbuger test
> 	PROGRAM tester
> 	INTEGER i
> 	REAl(8) a
> 	DIMENSION b(3)
> c
> 	WRITE(*,*) 'Insert a number'
> 	READ(*,*) a
> c
> 	b=1.d0
> 	DO i=1,3
> 		b(i) = a**i
> 	ENDDO
> c
> 	END
> CVF build my code.
> I launch the debug.
> I insert '5'.
> My debus doesn't go on and I get This output:
> Loaded 'ntdll.dll', no matching symbolic information found.
> Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic
> information found.
....
> The thread 0xF0 has exited with code 0 (0x0).
> The program 'C:\FORTRAN\sandorn\Debug\sandorn.exe' has exited with
> code 0 (0x0).

Did you set a breakpoint somewhere?

I don't know why you get the full list of so many; if I don't set a 
breakpoint I get the ntdll and kernel32 messages as well altho not any 
of the others.  The point is, however, that the app ran to completion as 
the final message says.

If I set a breakpoint in an app, the app starts and halts in the 
debugger at the breakpoint and all is well...

If that doesn't happen or you want more details specifically on what/why 
you're seeing such a long list of system dlls after the app terminates 
the Intel forum would be the place to ask as they (Intel) are the 
follow-on of the legacy of D/CVF as Intel bought the compiler and the 
team moved to Intel.  Altho IVF is a new compiler, the resident 
expertise on CVF resides there and they do provide responses in the user 
forum.

--