[Bryan See]

Hello again,

I've been using FRED (both release and debug builds) without administrative privileges on Windows 10, which is known to have cause stability issues.

I'm running the debug build of FRED via VS2015 Community Edition. At one point, I've got the assert message on wings.cpp:

Code: [Select]

Assert: Wings[wing].special_ship >= 0 && Wings[wing].special_ship < Wings[wing].wave_count
File: wing.cpp
Line: 65

ntdll.dll! NtWaitForSingleObject + 12 bytes
KERNELBASE.dll! WaitForSingleObject + 18 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! SCP_DumpStack + 354 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! WinAssert + 194 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! mark_wing + 103 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! wing_editor::OnPrev + 202 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! _AfxDispatchCmdMsg + 195 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CCmdTarget::OnCmdMsg + 858 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CDialog::OnCmdMsg + 66 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::OnCommand + 416 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! wing_editor::OnCommand + 127 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::OnWndMsg + 134 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::WindowProc + 68 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! AfxCallWndProc + 267 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! AfxWndProc + 181 bytes
USER32.dll! CharNextW + 115 bytes
USER32.dll! CallWindowProcW + 768 bytes
USER32.dll! DispatchMessageW + 1328 bytes
USER32.dll! PeekMessageW + 1353 bytes
ntdll.dll! KiUserCallbackDispatcher + 54 bytes
USER32.dll! SendMessageW + 323 bytes
USER32.dll! LoadCursorFromFileW + 16683 bytes
USER32.dll! LoadCursorFromFileW + 15288 bytes
USER32.dll! LoadCursorFromFileW + 8738 bytes
USER32.dll! LoadCursorFromFileW + 5842 bytes
USER32.dll! CharNextW + 115 bytes
USER32.dll! CallWindowProcW + 768 bytes
USER32.dll! DispatchMessageW + 593 bytes
USER32.dll! IsDialogMessageW + 257 bytes
USER32.dll! IsDialogMessage + 78 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::IsDialogMessageA + 148 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::PreTranslateInput + 125 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CDialog::PreTranslateMessage + 297 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWnd::WalkPreTranslateTree + 174 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! AfxInternalPreTranslateMessage + 99 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWinThread::PreTranslateMessage + 42 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! AfxPreTranslateMessage + 45 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! AfxInternalPumpMessage + 253 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWinThread::PumpMessage + 19 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWinThread::Run + 180 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! CWinApp::Run + 108 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! AfxWinMain + 308 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! WinMain + 24 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! invoke_main + 30 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! __scrt_common_main_seh + 346 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! __scrt_common_main + 13 bytes
fred2_open_3_7_3_AVX-DEBUG.exe! WinMainCRTStartup + 8 bytes
KERNEL32.DLL! BaseThreadInitThunk + 36 bytes
ntdll.dll! RtlSetCurrentTransaction + 212 bytes
ntdll.dll! RtlSetCurrentTransaction + 159 bytes

At one point at the wings section of the mission file, one of the wings' arrival location is changed to "Cable TV", and the Special Ship is set to a negative value of 1.

Code: [Select]

$Special Ship: -1 ;! Brahma 1

$Arrival Location: Cable TV
...
$Departure Anchor: <error>

Going to upload one of my large missions on GitHub very soon to test it out.

EDIT: To clarify the problem of special ship negative value and the arrival location as Cable TV.

EDIT #2: To clarify the problem of departure anchor set to <error>.

[mjn.mixael]

For whatever it's worth.. I've been FREDing on Win10 for a few weeks with no stability issues.

[AdmiralRalwood]

Something has gone horribly wrong if "Arrival Location" is getting set to "Cable TV"; if I had to guess, the arrival_location is probably also -1, because an out-of-bounds array access is the only way I can think of for that string to get written there (and "Cable TV" is the last string of the previously-defined array). In fact, the "$Departure Anchor: <error>" is also only written if the departure_anchor is negative, so it sounds like an object with nothing but the default initialization values is getting saved for some reason.

[Bryan See]

Running FRED2_OPEN AVX via MSVS2015 Community edition with all C++ and Win32 exceptions enabled at Exception Settings, it appears that everytime on startup, there is a parse error when attempting to open "armor.tbl" file, which is optionally required to exist while being built-in. It may be one of the causes FRED2_OPEN AVX crashing at various intervals, whether it is inactive or not. However, I do plan to test it more.

Call Stack:

Code: [Select]

> fred2_open_3_7_3_AVX-DEBUG.exe!read_raw_file_text(const char * filename, int mode, char * raw_text) Line 2117 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!read_file_text(const char * filename, int mode, char * processed_text, char * raw_text) Line 1987 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!armor_parse_table(const char * filename) Line 18325 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!armor_init() Line 18351 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!fred_init() Line 410 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CFREDView::OnCreate(tagCREATESTRUCTA * lpCreateStruct) Line 4677 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult) Line 2387 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam) Line 2078 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 265 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 418 C++
  [External Code]
  fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::Create(const char * lpszClassName, const char * lpszWindowName, unsigned long dwStyle, const tagRECT & rect, CWnd * pParentWnd, unsigned int nID, CCreateContext * pContext) Line 785 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::CreateView(CCreateContext * pContext, unsigned int nID) Line 653 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::OnCreateClient(tagCREATESTRUCTA * __formal, CCreateContext * pContext) Line 675 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::OnCreateHelper(tagCREATESTRUCTA * lpcs, CCreateContext * pContext) Line 694 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::OnCreate(tagCREATESTRUCTA * lpcs) Line 686 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CMainFrame::OnCreate(tagCREATESTRUCTA * lpCreateStruct) Line 108 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult) Line 2387 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam) Line 2078 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 265 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 418 C++
  [External Code]
  fred2_open_3_7_3_AVX-DEBUG.exe!IsolationAwareCreateWindowExA(unsigned long dwExStyle, const char * lpClassName, const char * lpWindowName, unsigned long dwStyle, int X, int Y, int nWidth, int nHeight, HWND__ * hWndParent, HMENU__ * hMenu, HINSTANCE__ * hInstance, void * lpParam) Line 423 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CWnd::CreateEx(unsigned long dwExStyle, const char * lpszClassName, const char * lpszWindowName, unsigned long dwStyle, int x, int y, int nWidth, int nHeight, HWND__ * hWndParent, HMENU__ * nIDorHMenu, void * lpParam) Line 724 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::Create(const char * lpszClassName, const char * lpszWindowName, unsigned long dwStyle, const tagRECT & rect, CWnd * pParentWnd, const char * lpszMenuName, unsigned long dwExStyle, CCreateContext * pContext) Line 622 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CFrameWnd::LoadFrame(unsigned int nIDResource, unsigned long dwDefaultStyle, CWnd * pParentWnd, CCreateContext * pContext) Line 755 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CDocTemplate::CreateNewFrame(CDocument * pDoc, CFrameWnd * pOther) Line 292 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CSingleDocTemplate::OpenDocumentFile(const char * lpszPathName, int bAddToMRU, int bMakeVisible) Line 133 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CSingleDocTemplate::OpenDocumentFile(const char * lpszPathName, int bMakeVisible) Line 83 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CDocManager::OnFileNew() Line 912 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CWinApp::OnFileNew() Line 21 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!CFREDApp::InitInstance() Line 259 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 37 C++
  fred2_open_3_7_3_AVX-DEBUG.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 26 C++
Autos:

Code: [Select]

+ filename 0x01201a48 "armor.tbl" const char *
+ mf 0x00000000 <NULL> CFILE *


[m!m]

Why have you enabled the C++ exception breakpoints? C++ exceptions are regularly thrown in the code without causing any issues. You only need to enable the Win32 breakpoints because those are needed when the executable crashes.

[The E]

And no, Bryan, a missing armor.tbl (or a missing scripting.html) will never, ever cause problems.

[Bryan See]

I've got an issue about ship subsystems when changing ship classes.

Code: [Select]

Assert: subsys_pcts[num_saved_subsystems] >= 0.0f && subsys_pcts[num_saved_subsystems] <= 1.0f
File: ship.cpp
Line: 10031

ntdll.dll! ZwWaitForSingleObject + 12 bytes
KERNELBASE.dll! WaitForSingleObject + 18 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! SCP_DumpStack + 354 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! WinAssert + 194 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! change_ship_type + 1281 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CShipEditorDlg::OnSelchangeShipClass + 161 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! _AfxDispatchCmdMsg + 195 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CCmdTarget::OnCmdMsg + 858 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CDialog::OnCmdMsg + 66 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::OnCommand + 416 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CShipEditorDlg::OnCommand + 142 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::OnWndMsg + 134 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::WindowProc + 68 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxCallWndProc + 267 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxWndProc + 181 bytes
USER32.dll! SetManipulationInputTarget + 83 bytes
USER32.dll! CallWindowProcW + 768 bytes
USER32.dll! DispatchMessageW + 1328 bytes
USER32.dll! PeekMessageW + 1369 bytes
ntdll.dll! KiUserCallbackDispatcher + 54 bytes
USER32.dll! Ordinal1502 + 10560 bytes
USER32.dll! Ordinal1502 + 6241 bytes
USER32.dll! Ordinal1502 + 3354 bytes
USER32.dll! Ordinal1502 + 987 bytes
USER32.dll! SetManipulationInputTarget + 83 bytes
USER32.dll! CallWindowProcW + 768 bytes
USER32.dll! DispatchMessageW + 1328 bytes
USER32.dll! PeekMessageW + 1369 bytes
ntdll.dll! KiUserCallbackDispatcher + 54 bytes
USER32.dll! SendMessageW + 323 bytes
USER32.dll! DdeQueryStringW + 14891 bytes
USER32.dll! Ordinal2573 + 1723 bytes
USER32.dll! Ordinal2573 + 262 bytes
USER32.dll! SetManipulationInputTarget + 83 bytes
USER32.dll! CallWindowProcW + 768 bytes
USER32.dll! DispatchMessageW + 593 bytes
USER32.dll! DispatchMessageA + 16 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxInternalPumpMessage + 297 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::PumpMessage + 19 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::Run + 180 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWinApp::Run + 108 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxWinMain + 308 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! WinMain + 24 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! invoke_main + 30 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main_seh + 346 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main + 13 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! WinMainCRTStartup + 8 bytes
KERNEL32.DLL! BaseThreadInitThunk + 36 bytes
ntdll.dll! RtlUnicodeStringToInteger + 595 bytes
ntdll.dll! RtlUnicodeStringToInteger + 542 bytes


[herkie423]

Something has gone horribly wrong if "Arrival Location" is getting set to "Cable TV"; if I had to guess, the arrival_location is probably also -1, because an out-of-bounds array access is the only way I can think of for that string to get written there (and "Cable TV" is the last string of the previously-defined array). In fact, the "$Departure Anchor: <error>" is also only written if the departure_anchor is negative, so it sounds like an object with nothing but the default initialization values is getting saved for some reason.

I got this error in the last mission of "The Aftermath" - - - "wing out of bounds" I did not know what happen when it got saved by the FRED. But I managed to solved it by editing the mission file using notepad and replaced the "Cable TV" value with "hyperspace" (Default value) and setting the departure anchor to its proper value, 0. Then open the mission again in FRED and save. I suspect that this will happen if you have a lot ships in the Frey. The last mission in my campaign consist of one hundred fighter wings. All hell broke loose.

[Bryan See]

And I've got another issue, this time about deleting messages when the selected message is empty.

Code: [Select]

Assert: (m_cur_msg >= 0) && (m_cur_msg < m_num_messages)
File: eventeditor.cpp
Line: 1302

ntdll.dll! ZwWaitForSingleObject + 12 bytes
KERNELBASE.dll! WaitForSingleObject + 18 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! SCP_DumpStack + 354 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! WinAssert + 194 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! event_editor::OnDeleteMsg + 91 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! _AfxDispatchCmdMsg + 195 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CCmdTarget::OnCmdMsg + 858 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CDialog::OnCmdMsg + 66 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::OnCommand + 416 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::OnWndMsg + 134 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::WindowProc + 68 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxCallWndProc + 267 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxWndProc + 181 bytes
USER32.dll! SetManipulationInputTarget + 83 bytes
USER32.dll! CallWindowProcW + 768 bytes
USER32.dll! DispatchMessageW + 1328 bytes
USER32.dll! PeekMessageW + 1369 bytes
ntdll.dll! KiUserCallbackDispatcher + 54 bytes
USER32.dll! SendMessageW + 323 bytes
USER32.dll! LoadCursorFromFileW + 16683 bytes
USER32.dll! LoadCursorFromFileW + 15288 bytes
USER32.dll! LoadCursorFromFileW + 8738 bytes
USER32.dll! LoadCursorFromFileW + 5842 bytes
USER32.dll! SetManipulationInputTarget + 83 bytes
USER32.dll! CallWindowProcW + 768 bytes
USER32.dll! DispatchMessageW + 593 bytes
USER32.dll! IsDialogMessageW + 235 bytes
USER32.dll! IsDialogMessage + 78 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::IsDialogMessageA + 148 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::PreTranslateInput + 125 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CDialog::PreTranslateMessage + 297 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWnd::WalkPreTranslateTree + 174 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxInternalPreTranslateMessage + 99 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::PreTranslateMessage + 42 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxPreTranslateMessage + 45 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxInternalPumpMessage + 253 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::PumpMessage + 19 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWinThread::Run + 180 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! CWinApp::Run + 108 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! AfxWinMain + 308 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! WinMain + 24 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! invoke_main + 30 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main_seh + 346 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! __scrt_common_main + 13 bytes
fred2_open_3_7_3_SSE2-DEBUG.exe! WinMainCRTStartup + 8 bytes
KERNEL32.DLL! BaseThreadInitThunk + 36 bytes
ntdll.dll! RtlUnicodeStringToInteger + 595 bytes
ntdll.dll! RtlUnicodeStringToInteger + 542 bytes


[AdmiralRalwood]

And I've got another issue, this time about deleting messages when the selected message is empty.

Code: [Select]

Assert: (m_cur_msg >= 0) && (m_cur_msg < m_num_messages)
File: eventeditor.cpp
Line: 1302

It looks like the code allows this function to be called when m_cur_msg is -1 (meaning there are no messages defined by the mission), making this assertion incorrect (should probably be >= -1 instead). Obvious workaround while waiting for the PR: don't try to delete a message when there's no message to delete in a Debug build.

[Bryan See]

I think the solution is when there are no messages in the mission or there are no messages selected, the delete button must be greyed out.

[The E]

This error has been fixed here: https://github.com/scp-fs2open/fs2open.github.com/pull/447

[Bryan See]

Thanks, The E for this.

Something has gone horribly wrong if "Arrival Location" is getting set to "Cable TV"; if I had to guess, the arrival_location is probably also -1, because an out-of-bounds array access is the only way I can think of for that string to get written there (and "Cable TV" is the last string of the previously-defined array). In fact, the "$Departure Anchor: <error>" is also only written if the departure_anchor is negative, so it sounds like an object with nothing but the default initialization values is getting saved for some reason.

I got this error in the last mission of "The Aftermath" - - - "wing out of bounds" I did not know what happen when it got saved by the FRED. But I managed to solved it by editing the mission file using notepad and replaced the "Cable TV" value with "hyperspace" (Default value) and setting the departure anchor to its proper value, 0. Then open the mission again in FRED and save. I suspect that this will happen if you have a lot ships in the Frey. The last mission in my campaign consist of one hundred fighter wings. All hell broke loose.

Are there any solution to this?

[The E]

No, because we do not have enough info at this time to reproduce and fix that issue.

[Black-Sheep]

Hello,

i am quite new to fred.

however i tryed version 3.7.3 SSE2 (as intel i-Core) and the standard versions.

Both don't start
no error nothing, just the "busy" mouse pointer.

Using Windows 10, 64-Bit, tryed to run as Administrator and with Win7 Compatibility mode.
Nothing works.

any suggestions?

[Goober5000]

Does FreeSpace have the same problem?

Please post your fred2_open.log file.  Instructions on how to do this can be found in this post.  (The procedure is the same for fs2_open.log and fred2_open.log, except for the name.)

[Black-Sheep]

Thanks for the Reply,

Freespace 2 runs BluePlanet Complete von the 3.7.3.exe no Problem, crash or anything with it - it just loads normaly and runs perfectly.

FRED however does not do anything at all. Nada.
It doesn't even crash.

While i do have a "busy" mouse icon (the Blue circle of windows next to the mouse) after trying to start it, it never actually starts.
There is not even a TASK to be observed while it try to start it.
As it's not starting it's alsow not crashing - the result is a not existend log file

i double checked - but no, i don't have a fred2_open.log file on my PC

i know this sounds totaly strange and - while beeing a certified microsoft Admin - i can tell you this is indeed strange.... there is no IO whatsover... Windows Eventlog is empty too....

is it possible that FRED needs somekind of .NET framework Freespace alone does not need? (maybe windows 10 is missing a few librarys?)

[niffiwan]

I've heard of cases where the AV has done something to FSO that stops it running, perhaps on your PC it's done something similar to FRED?